internal/runtime/gc/scan: avoid memory destination on VPCOMPRESSQ

On AMD Genoa / Zen 4, VPCOMPRESSQ with a memory destination imposes a
severe performance penalty of another an order of magnitude compared to
a register destination.

We can trivially work around this penalty with a register destination
and an additional move to memory.

Benchmark results from:

$ go test -bench=BenchmarkScanSpanPacked/.*/.*/.*/.*/impl=Platform internal/runtime/gc/scan

I've only included the summarized geomean here because there are ~2500
unique test cases.

AMD Genoa (Zen 4):

cpu: AMD EPYC 9B14 96-Core Processor
         │      mem      │                 reg        │
         │    sec/op     │    sec/op     vs base      │
geomean     1.039µ         310.1n        -70.16%

         │      mem      │                  reg       │
         │      B/s      │      B/s        vs base    │
geomean    2.906Gi          10.99Gi        +278.27%

As expected, we see a massive performance improvement on Genoa.

AMD Turin (Zen 5):

cpu: AMD EPYC 9B45 128-Core Processor
         │      mem      │                 reg        │
         │    sec/op     │    sec/op      vs base     │
geomean     231.9n          237.3n         +2.32%

         │      mem       │                  reg      │
         │      B/s       │      B/s        vs base   │
geomean     14.79Gi          14.43Gi         -2.50%

On Turin there is a minor regression. This is primarily due to a fairly
large regression (~15%) in very small microbenchmark cases where the
entire memory fits in L1 cache. This regression disappears as memory
access slows down with larger memories. The latter should be more common
in real workloads.

Intel Sapphire Rapids:

cpu: Intel(R) Xeon(R) Platinum 8481C
         │      mem      │                 reg        │
         │    sec/op     │    sec/op      vs base     │
geomean     254.9n          246.8n         -3.18%

         │      mem       │                  reg      │
         │      B/s       │      B/s        vs base   │
geomean     13.65Gi          14.15Gi         +3.69%

On Sapphire Rapids there is a minor improvement. Here results are fairly
noisy. Most cases are a wash, but some are arbitrary 20% slower or 20%
faster for unclear reasons.

For #73581.

Change-Id: I6a6a636cfd294a0dcdc4f34c9ece1bc9a6e5e4c7
Reviewed-on: https://go-review.googlesource.com/c/go/+/715362
Reviewed-by: Michael Knyszek <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Michael Pratt <mpratt@google.com>
Reviewed-by: Junyang Shao <shaojunyang@google.com>

0 files changed, 0 insertions, 0 deletions