Improve Span.Count

[MihaZupan]

We're currently calculating the number of remaining elements after the vectorized loop and falling back to the scalar path if we have less than half a vector's worth of data remaining.

It's simpler and faster if we just unconditionally process the last vector.

publicclassCountBenchmarks<T>whereT:struct,INumber<T>{privateT[][]_numbers;[GlobalSetup]publicvoidSetup(){_numbers=newT[10_000][];varrng=newRandom(42);for(inti=0;i<_numbers.Length;i++){_numbers[i]=newT[rng.Next(0,256/Unsafe.SizeOf<T>())];rng.NextBytes(MemoryMarshal.AsBytes(_numbers[i].AsSpan()));}}[Benchmark]publicintCount(){intcount=0;foreach(T[]numbersin_numbers)count+=numbers.AsSpan().Count(T.CreateChecked(42));returncount;}}

Method	Toolchain	Type	Mean	Error	Ratio
Count	main	byte	175.4 us	0.82 us	1.00
Count	pr	byte	100.1 us	0.25 us	0.57
Count	main	short	147.6 us	0.24 us	1.00
Count	pr	short	102.7 us	0.17 us	0.70
Count	main	int	143.01 us	0.277 us	1.00
Count	pr	int	98.10 us	0.262 us	0.69
Count	main	long	134.13 us	2.157 us	1.00
Count	pr	long	99.87 us	0.618 us	0.74

@gfoidl this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

[dotnet-policy-service]

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

[gfoidl]

this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

Probably. At least your benchmark (w/ different length) seems better. So a nice improvement.

[MihaZupan]

We're currently calculating the number of remaining elements after the vectorized loop and falling back to the scalar path if we have less than half a vector's worth of data remaining.

It's simpler and faster if we just unconditionally process the last vector.

publicclassCountBenchmarks<T>whereT:struct,INumber<T>{privateT[][]_numbers;[GlobalSetup]publicvoidSetup(){_numbers=newT[10_000][];varrng=newRandom(42);for(inti=0;i<_numbers.Length;i++){_numbers[i]=newT[rng.Next(0,256/Unsafe.SizeOf<T>())];rng.NextBytes(MemoryMarshal.AsBytes(_numbers[i].AsSpan()));}}[Benchmark]publicintCount(){intcount=0;foreach(T[]numbersin_numbers)count+=numbers.AsSpan().Count(T.CreateChecked(42));returncount;}}

Method	Toolchain	Type	Mean	Error	Ratio
Count	main	byte	175.4 us	0.82 us	1.00
Count	pr	byte	100.1 us	0.25 us	0.57
Count	main	short	147.6 us	0.24 us	1.00
Count	pr	short	102.7 us	0.17 us	0.70
Count	main	int	143.01 us	0.277 us	1.00
Count	pr	int	98.10 us	0.262 us	0.69
Count	main	long	134.13 us	2.157 us	1.00
Count	pr	long	99.87 us	0.618 us	0.74

@gfoidl this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

[dotnet-policy-service]

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

[gfoidl]

this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

Probably. At least your benchmark (w/ different length) seems better. So a nice improvement.

[MihaZupan]

We're currently calculating the number of remaining elements after the vectorized loop and falling back to the scalar path if we have less than half a vector's worth of data remaining.

It's simpler and faster if we just unconditionally process the last vector.

publicclassCountBenchmarks<T>whereT:struct,INumber<T>{privateT[][]_numbers;[GlobalSetup]publicvoidSetup(){_numbers=newT[10_000][];varrng=newRandom(42);for(inti=0;i<_numbers.Length;i++){_numbers[i]=newT[rng.Next(0,256/Unsafe.SizeOf<T>())];rng.NextBytes(MemoryMarshal.AsBytes(_numbers[i].AsSpan()));}}[Benchmark]publicintCount(){intcount=0;foreach(T[]numbersin_numbers)count+=numbers.AsSpan().Count(T.CreateChecked(42));returncount;}}

Method	Toolchain	Type	Mean	Error	Ratio
Count	main	byte	175.4 us	0.82 us	1.00
Count	pr	byte	100.1 us	0.25 us	0.57
Count	main	short	147.6 us	0.24 us	1.00
Count	pr	short	102.7 us	0.17 us	0.70
Count	main	int	143.01 us	0.277 us	1.00
Count	pr	int	98.10 us	0.262 us	0.69
Count	main	long	134.13 us	2.157 us	1.00
Count	pr	long	99.87 us	0.618 us	0.74

@gfoidl this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

[dotnet-policy-service]

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

[gfoidl]

this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

Probably. At least your benchmark (w/ different length) seems better. So a nice improvement.

[MihaZupan]

We're currently calculating the number of remaining elements after the vectorized loop and falling back to the scalar path if we have less than half a vector's worth of data remaining.

It's simpler and faster if we just unconditionally process the last vector.

publicclassCountBenchmarks<T>whereT:struct,INumber<T>{privateT[][]_numbers;[GlobalSetup]publicvoidSetup(){_numbers=newT[10_000][];varrng=newRandom(42);for(inti=0;i<_numbers.Length;i++){_numbers[i]=newT[rng.Next(0,256/Unsafe.SizeOf<T>())];rng.NextBytes(MemoryMarshal.AsBytes(_numbers[i].AsSpan()));}}[Benchmark]publicintCount(){intcount=0;foreach(T[]numbersin_numbers)count+=numbers.AsSpan().Count(T.CreateChecked(42));returncount;}}

Method	Toolchain	Type	Mean	Error	Ratio
Count	main	byte	175.4 us	0.82 us	1.00
Count	pr	byte	100.1 us	0.25 us	0.57
Count	main	short	147.6 us	0.24 us	1.00
Count	pr	short	102.7 us	0.17 us	0.70
Count	main	int	143.01 us	0.277 us	1.00
Count	pr	int	98.10 us	0.262 us	0.69
Count	main	long	134.13 us	2.157 us	1.00
Count	pr	long	99.87 us	0.618 us	0.74

@gfoidl this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

[dotnet-policy-service]

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

[gfoidl]

this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

Probably. At least your benchmark (w/ different length) seems better. So a nice improvement.

[MihaZupan]

We're currently calculating the number of remaining elements after the vectorized loop and falling back to the scalar path if we have less than half a vector's worth of data remaining.

It's simpler and faster if we just unconditionally process the last vector.

publicclassCountBenchmarks<T>whereT:struct,INumber<T>{privateT[][]_numbers;[GlobalSetup]publicvoidSetup(){_numbers=newT[10_000][];varrng=newRandom(42);for(inti=0;i<_numbers.Length;i++){_numbers[i]=newT[rng.Next(0,256/Unsafe.SizeOf<T>())];rng.NextBytes(MemoryMarshal.AsBytes(_numbers[i].AsSpan()));}}[Benchmark]publicintCount(){intcount=0;foreach(T[]numbersin_numbers)count+=numbers.AsSpan().Count(T.CreateChecked(42));returncount;}}

Method	Toolchain	Type	Mean	Error	Ratio
Count	main	byte	175.4 us	0.82 us	1.00
Count	pr	byte	100.1 us	0.25 us	0.57
Count	main	short	147.6 us	0.24 us	1.00
Count	pr	short	102.7 us	0.17 us	0.70
Count	main	int	143.01 us	0.277 us	1.00
Count	pr	int	98.10 us	0.262 us	0.69
Count	main	long	134.13 us	2.157 us	1.00
Count	pr	long	99.87 us	0.618 us	0.74

@gfoidl this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

[dotnet-policy-service]

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

[gfoidl]

this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

Probably. At least your benchmark (w/ different length) seems better. So a nice improvement.

[MihaZupan]

We're currently calculating the number of remaining elements after the vectorized loop and falling back to the scalar path if we have less than half a vector's worth of data remaining.

It's simpler and faster if we just unconditionally process the last vector.

publicclassCountBenchmarks<T>whereT:struct,INumber<T>{privateT[][]_numbers;[GlobalSetup]publicvoidSetup(){_numbers=newT[10_000][];varrng=newRandom(42);for(inti=0;i<_numbers.Length;i++){_numbers[i]=newT[rng.Next(0,256/Unsafe.SizeOf<T>())];rng.NextBytes(MemoryMarshal.AsBytes(_numbers[i].AsSpan()));}}[Benchmark]publicintCount(){intcount=0;foreach(T[]numbersin_numbers)count+=numbers.AsSpan().Count(T.CreateChecked(42));returncount;}}

Method	Toolchain	Type	Mean	Error	Ratio
Count	main	byte	175.4 us	0.82 us	1.00
Count	pr	byte	100.1 us	0.25 us	0.57
Count	main	short	147.6 us	0.24 us	1.00
Count	pr	short	102.7 us	0.17 us	0.70
Count	main	int	143.01 us	0.277 us	1.00
Count	pr	int	98.10 us	0.262 us	0.69
Count	main	long	134.13 us	2.157 us	1.00
Count	pr	long	99.87 us	0.618 us	0.74

@gfoidl this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

[dotnet-policy-service]

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

[gfoidl]

this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

Probably. At least your benchmark (w/ different length) seems better. So a nice improvement.

[MihaZupan]

We're currently calculating the number of remaining elements after the vectorized loop and falling back to the scalar path if we have less than half a vector's worth of data remaining.

It's simpler and faster if we just unconditionally process the last vector.

publicclassCountBenchmarks<T>whereT:struct,INumber<T>{privateT[][]_numbers;[GlobalSetup]publicvoidSetup(){_numbers=newT[10_000][];varrng=newRandom(42);for(inti=0;i<_numbers.Length;i++){_numbers[i]=newT[rng.Next(0,256/Unsafe.SizeOf<T>())];rng.NextBytes(MemoryMarshal.AsBytes(_numbers[i].AsSpan()));}}[Benchmark]publicintCount(){intcount=0;foreach(T[]numbersin_numbers)count+=numbers.AsSpan().Count(T.CreateChecked(42));returncount;}}

Method	Toolchain	Type	Mean	Error	Ratio
Count	main	byte	175.4 us	0.82 us	1.00
Count	pr	byte	100.1 us	0.25 us	0.57
Count	main	short	147.6 us	0.24 us	1.00
Count	pr	short	102.7 us	0.17 us	0.70
Count	main	int	143.01 us	0.277 us	1.00
Count	pr	int	98.10 us	0.262 us	0.69
Count	main	long	134.13 us	2.157 us	1.00
Count	pr	long	99.87 us	0.618 us	0.74

@gfoidl this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

[dotnet-policy-service]

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

[gfoidl]

this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

Probably. At least your benchmark (w/ different length) seems better. So a nice improvement.

[MihaZupan]

We're currently calculating the number of remaining elements after the vectorized loop and falling back to the scalar path if we have less than half a vector's worth of data remaining.

It's simpler and faster if we just unconditionally process the last vector.

publicclassCountBenchmarks<T>whereT:struct,INumber<T>{privateT[][]_numbers;[GlobalSetup]publicvoidSetup(){_numbers=newT[10_000][];varrng=newRandom(42);for(inti=0;i<_numbers.Length;i++){_numbers[i]=newT[rng.Next(0,256/Unsafe.SizeOf<T>())];rng.NextBytes(MemoryMarshal.AsBytes(_numbers[i].AsSpan()));}}[Benchmark]publicintCount(){intcount=0;foreach(T[]numbersin_numbers)count+=numbers.AsSpan().Count(T.CreateChecked(42));returncount;}}

Method	Toolchain	Type	Mean	Error	Ratio
Count	main	byte	175.4 us	0.82 us	1.00
Count	pr	byte	100.1 us	0.25 us	0.57
Count	main	short	147.6 us	0.24 us	1.00
Count	pr	short	102.7 us	0.17 us	0.70
Count	main	int	143.01 us	0.277 us	1.00
Count	pr	int	98.10 us	0.262 us	0.69
Count	main	long	134.13 us	2.157 us	1.00
Count	pr	long	99.87 us	0.618 us	0.74

@gfoidl this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

[dotnet-policy-service]

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

[gfoidl]

this goes against your numbers in #82687, presumably because you were testing with a single Length at a time and all the branches were predictable?

Probably. At least your benchmark (w/ different length) seems better. So a nice improvement.