Improve System.Collections.BitArray #115069
Conversation
|
Tagging subscribers to this area: @dotnet/area-system-collections |
| @@ -348,23 +348,23 @@ public BitArray And(BitArray value) | |||
| ref int right = ref MemoryMarshal.GetArrayDataReference<int>(valueArray); | |||
| if (Vector512.IsHardwareAccelerated && (uint)count >= Vector512<int>.Count) | |||
| { | |||
| for (; i < (uint)count - (Vector512<int>.Count - 1u); i += (uint)Vector512<int>.Count) | |||
| for (; i < (uint)count - ((uint)Vector512<int>.Count - 1u); i += (uint)Vector512<int>.Count) | |||
There was a problem hiding this comment.
Mixing int and uint causes both to be extended to long, and 64bit arithmetic is slow in 32bit processes.
There was a problem hiding this comment.
The question is more "why use uint at all here"?
Just use the standard int i = 0 instead and if then do LoadUnsafe(ref left, (uint)i) if you want to zero-extend the load.
There was a problem hiding this comment.
It seems #33749 decided to use uint i instead of int i to avoid potential overflows. I don't see any potential overflow to necessitate uint i in the current version of BitArray.cs, though. Should I change all those uint i to int i?
There was a problem hiding this comment.
There shouldn't be any risk to overflow even in the previous implementation. The loop should never be incrementing past Length in the first place.
Using int tends to work better for the JIT and unlocks more overall optimizations. It will also improve readability here.
src/libraries/System.Collections/src/System/Collections/BitArray.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Collections/src/System/Collections/BitArray.cs
Outdated
Show resolved
Hide resolved
| else | ||
| { | ||
| shuffled = Vector512.Shuffle(bits.AsByte(), | ||
| Vector512.Create(0x03030303_03030303, 0x0A0A0A0A_0A0A0A0A, 0x11111111_11111111, 0x18181818_18181818, | ||
| 0x27272727_27272727, 0x2E2E2E2E_2E2E2E2E, 0x35353535_35353535, 0x3C3C3C3C_3C3C3C3C).AsByte()); | ||
| } |
There was a problem hiding this comment.
I don't think there's any big endian platform that's supported and also supports vectors, I'd recommend just guarding the SIMD paths on LE here.
There was a problem hiding this comment.
I have already wrote these lines, so why not keep them
There was a problem hiding this comment.
I have already wrote these lines, so why not keep them
Cause having dead, untested code both complicates the algorithm and can cause unexpected bugs if those paths get enabled later.
There was a problem hiding this comment.
The original AdvSimd.Arm64 path also has a big endian sub-path.
can cause unexpected bugs if those paths get enabled later.
If any big endian platform with vectors gets supported, all these libraries that come with the runtime itself will be recompiled and their tests will be run. It will also be a use case and test case for VectorXXX.Shuffle.
| Vector256<byte> isFalse = Vector256.Equals(vector, Vector256<byte>.Zero); | ||
|
|
||
| uint result = isFalse.ExtractMostSignificantBits(); | ||
| m_array[i / 32u] = (int)(~result); | ||
| m_array[i / 32] = (int)~(isFalse.ExtractMostSignificantBits()); | ||
| } | ||
| } | ||
| else if (Vector128.IsHardwareAccelerated) |
There was a problem hiding this comment.
All the other similar code dropped the else for this branch.
There was a problem hiding this comment.
Here, the loop conditions for Vector256 and Vector128 paths are basically same (i <= values.Length - 32), so there is no point executing the Vector128 path if the Vector256 path is already executed.
Use xplat SIMD intrinsics in
BitArray.CopyTo. #114818 (comment)Other minor improvements.