coreclr.dll regressed by ~300kB due to vxsort

[jkotas]

coreclr.dll sizes

64c9e7c 4,728,832
69b0d16 5,027,840

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jkotas]

Is it really expected for vxsort to be 300kB of code? That's almost as much as the rest of the GC.

[jkotas]

cc @PeterSolMS

Tagging subscribers to this area: @dotnet/gc
Notify danmosemsft if you want to be subscribed.

[PeterSolMS]

Well, we have 4 flavors of the sorting code (two instruction sets - AVX2, AVX512F, and two types - int32_t and int64_t). We can limit the amount of inlining in the bitonic sorters that are called for small arrays - doing this immediately reduced the size of coreclr.dll by 180 kB. There are more tricks we can do, or dial back on the number of sorting code flavors.

[mangod9]

is avx512 significantly better to keep both implementations?

[PeterSolMS]

AVX512 is roughly about 2.2x faster than AVX2 for 64-bit elements, and about 1.4x faster for 32-bit elements, according to Dan Shechter's numbers. That is unless we're limited by memory bandwidth, in which case the difference is less. However, it's quite common to have one GC server thread take significantly longer than the others due to a larger mark list, in which case the other GC threads will have to wait. In that case, the difference in performance will definitely show up in pause time.

[MichalStrehovsky]

Does AVX-512 still have the throttling issues CloudFlare talked out here (would they affect us?).

At the end of the blog they basically recommend disabling AVX-512 unless one has some very specific tasks that rely on it.