GC's VXSort question

[EgorBo]

I noticed that GC uses VXSort (AVX2/AVX512) but only on Windows-x64. So I assume it has to be enabled for Linux-x64 and rewritten to NEON for Arm64?

(a screenshot, because it's not possible to reference lines in gc.cpp via github 😄)

I only tested it on Plaintext-MVC benchmark (allocates a lot of short-living objects) on our perf-lab and it seems like VXSort regresses P90 across 7 runs and has no effect on RPS. Also, it adds 227Kb to native size (for coreclr.dll+clrgc.dll combined)

Is there a scenario I can simulate on our perflab to see benefits from it or it only targets real world large workloads?
I am asking because I am wondering if it worth porting to NEON SIMD for arm64.

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I noticed that GC uses VXSort (AVX2/AVX512) but only on Windows-x64. So I assume it has to be enabled for Linux-x64 and rewritten to NEON for Arm64?

(a screenshot, because it's not possible to reference lines in gc.cpp via github 😄)

I only tested it on Plaintext-MVC benchmark (allocates a lot of short-living objects) on our perf-lab and it seems like it VXSort regresses P95 across 7 runs and has no effect on RPS. Also, it adds 227Kb to native size (for coreclr.dll+clrgc.dll combined)

Is there a scenario I can simulate on our perflab to see benefits from it or it only targets real world large workloads?
I am asking because I am wondering if it worth porting to NEON SIMD for arm64.

Author:	EgorBo
Assignees:	-
Labels:	area-Diagnostics-coreclr, untriaged
Milestone:	-

[ghost]

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

Issue Details

---

I noticed that GC uses VXSort (AVX2/AVX512) but only on Windows-x64. So I assume it has to be enabled for Linux-x64 and rewritten to NEON for Arm64?

(a screenshot, because it's not possible to reference lines in gc.cpp via github 😄)

I only tested it on Plaintext-MVC benchmark (allocates a lot of short-living objects) on our perf-lab and it seems like it VXSort regresses P95 across 7 runs and has no effect on RPS. Also, it adds 227Kb to native size (for coreclr.dll+clrgc.dll combined)

Is there a scenario I can simulate on our perflab to see benefits from it or it only targets real world large workloads?
I am asking because I am wondering if it worth porting to NEON SIMD for arm64.

Author:	EgorBo
Assignees:	-
Labels:	question, area-GC-coreclr, untriaged
Milestone:	-

[danmoseley]

@PeterSolMS

Linking #37159

[kunalspathak]

Some notes about INTROSORT is in #60166 (comment).

[Maoni0]

thanks @EgorBo for the data.

that's interesting because if you are just allocating some temp objects you shouldn't even hit the vectorized sorting code path. if you took a trace with cpu samples, do you see any samples captured in do_vxsort at all (or if you set a bp on do_vxsort do you see it get hit?)? just checking if it's a matter of "the benchmark is so small and any code change could disturb this" or is it really caused by the vectorized sorting.

[Maoni0]

I don't think this needs to be 7.0 but let me know if you don't agree.