Vectorize ProbabilisticMap.IndexOfAny

[MihaZupan]

AVX2

Method	Toolchain	NewLineFrequency	Length	Mean	Error	Ratio
ReplaceLineEndings	main	0	10000	11.481 us	0.0569 us	1.00
ReplaceLineEndings	pr	0	10000	1.086 us	0.0026 us	0.09
ReplaceLineEndings	main	0.05	10000	24.280 us	0.0478 us	1.00
ReplaceLineEndings	pr	0.05	10000	13.983 us	0.0596 us	0.58
ReplaceLineEndings	main	0.1	10000	35.616 us	0.1959 us	1.00
ReplaceLineEndings	pr	0.1	10000	27.322 us	0.3056 us	0.77
ReplaceLineEndings	main	0.2	10000	58.372 us	1.0346 us	1.00
ReplaceLineEndings	pr	0.2	10000	52.060 us	0.2331 us	0.89
ReplaceLineEndings	main	1	10000	160.760 us	1.1764 us	1.00
ReplaceLineEndings	pr	1	10000	201.541 us	4.8189 us	1.26

ARM64

Method	Length	Mean	Error
Old	10000	13.122 µs	0.0117 µs
New	10000	3.701 µs	0.0012 µs

Benchmark source

publicclassReplaceLineEndingsBenchmark{privatestring_input;[Params(0.0,0.05,0.1,0.2,1.0)]publicdoubleNewLineFrequency;[Params(10_000)]publicintLength;[GlobalSetup]publicvoidSetup(){char[]input=newchar[Length];varrng=newRandom(42);for(inti=0;i<input.Length;i++){if(rng.NextDouble()<NewLineFrequency){input[i]='\n';}else{charc;do{c=(char)rng.Next(0,65536);}while("\r\n\f\u0085\u2028\u2029".Contains(c));input[i]=c;}}_input=newstring(input);}[Benchmark]publicstringReplaceLineEndings()=>_input.ReplaceLineEndings();}

If we care, we could also do this for LastIndexOfAny.

#80297 could be interesting for ARM if we could do a 256-bit lookup instead of blending together smaller lookups.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-memory
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Method	Toolchain	NewLineFrequency	Length	Mean	Error	Ratio
ReplaceLineEndings	main	0	10000	11,172.53 ns	18.391 ns	1.00
ReplaceLineEndings	pr	0	10000	2,420.99 ns	5.713 ns	0.22
ReplaceLineEndings	main	0.05	10000	24,471.23 ns	167.827 ns	1.00
ReplaceLineEndings	pr	0.05	10000	15,055.74 ns	116.653 ns	0.62
ReplaceLineEndings	main	0.1	10000	37,305.05 ns	724.469 ns	1.00
ReplaceLineEndings	pr	0.1	10000	27,831.78 ns	862.877 ns	0.75
ReplaceLineEndings	main	0.2	10000	57,099.06 ns	305.187 ns	1.00
ReplaceLineEndings	pr	0.2	10000	47,964.65 ns	562.536 ns	0.84
ReplaceLineEndings	main	1	10000	160,707.06 ns	1,484.932 ns	1.00
ReplaceLineEndings	pr	1	10000	175,589.93 ns	3,588.352 ns	1.09

Benchmark source

publicclassReplaceLineEndingsBenchmark{privatestring_input;[Params(0.0,0.05,0.1,0.2,1.0)]publicdoubleNewLineFrequency;[Params(10_000)]publicintLength;[GlobalSetup]publicvoidSetup(){char[]input=newchar[Length];varrng=newRandom(42);for(inti=0;i<input.Length;i++){if(rng.NextDouble()<NewLineFrequency){input[i]='\n';}else{charc;do{c=(char)rng.Next(0,65536);}while("\r\n\f\u0085\u2028\u2029".Contains(c));input[i]=c;}}_input=newstring(input);}[Benchmark]publicstringReplaceLineEndings()=>_input.ReplaceLineEndings();}

If we care, we could also do this for LastIndexOfAny.

I don't know if it's possible to do something similar efficiently on ARM given that the bloom filter in this case is 256-bit.
We could experiment with different implementations that would vectorize well with Vector128.

Author:	MihaZupan
Assignees:	MihaZupan
Labels:	area-System.Memory
Milestone:	8.0.0

[MihaZupan]

/azp run runtime-libraries-coreclr outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[MihaZupan]

Added Vector{128/256}.LoadUnsafe(ref char) and Vector128.ShuffleUnsafe as internal APIs for now and replaced a few existing uses.

[lewing]

@radekdoulik we should add PackedSimd versions of the Unsafe* functions wasm supports to ease handling all the calling callers. I'm not sure we have a great pattern to simplify the *.IsHardwareAccelerated paths that works for all the cases yet but that is worth considering too.

[MihaZupan]

Any thoughts on this @dotnet/area-system-memory?

[tannergooding]

These are different because shifting via byte isn't accelerated on xarch, right?

[MihaZupan]

Yes. We do the same thing in IndexOfAnyAsciiSearcher as well, where that also feeds into a shuffle

[tannergooding]

👍, probably worth opening an issue so an efficient implementation can be done and we can avoid the separate paths here.

[MihaZupan]

#82564

[MihaZupan]

Failures are: #82575, #81123, #82611

[MihaZupan]

Anything else that should be changed here, or is this one good to merge @tannergooding?

[MihaZupan]

@tannergooding can this be merged? (I'm trying to avoid more merge conflicts as this was already rebased a fair number of times)

[tannergooding]

Another merge conflict popped up.

Would be good to see some more benchmark numbers to better display where the cutoff is for the index ratio.

Likely also needs a secondary review from someone like @stephentoub given the code its touching.

[stephentoub]

Thanks!