cmd/compile: on amd64, compiler's Zero operation is slower than memclrNoHeapPointers for 1024-2048 bytes

[matloob]

cc @randall77 @mknyszek

On amd64, it looks like memclrNoHeapPointers performs better than the code that the compiler substitutes it with for a constant length "Zero" SSA operation, for byte sizes between 1024 and 2048 bytes. In that range, memclrNoHeapPointers use avx2 instructions to do the clear, not using the rep stos until the size is at least 2048 bytes, while the compiler will generate a rep stos.

There's a comment in the assembly memclrNoHeapPointers about why that's done:

go/src/runtime/memclr_amd64.s

Line 47 in 96a6e14

// If the size is less than 2kb, do not use ERMS as it has a big start-up cost.

I put together a CL 681496 with some benchmarks those sizes and ran it on the C3 perf gomotes. I put the results in the change description.

I think in those cases we sholudn't turn memclrNoHeapPointers call with a constant size into a Zero? Or we could copy what memclrNoHeapPointers does?

Also: I haven't tested this, but there's a branch in the memclrNoHeapPointers that will have different behavior for clears 32M or larger so we may want to investigate that.

[gabyhelp]

Related Issues

• cmd/compile: For some sizes, zeroing memory through OpZero could be faster (AMD64) #56997

Related Code Changes

• cmd/compile/internal/ssa: use sse to zero on amd64
• cmd/compile: add memcrlelim SSA optimization pass
• cmd/compile: inline known-size memclrNoHeapPointers calls

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[randall77]

I was just looking at this code in an effort to get rid of things like the DUFFZERO operations. The relevant CL is https://go-review.googlesource.com/c/go/+/678937. Maybe this issue should wait until that code is in, because it is changing how Zero gets implemented.

I found a cutover between using SSE and rep stos at around 1.4KB. I'm sure this is heavily dependent on what particular chip you're on.

We can't use AVX in generated code without a feature check. A feature check isn't very expensive, especially compared to writing more than a kilobyte, but it does mean ~2x the generated code because we need a fallback strategy.

[cherrymui]

We can't use AVX in generated code without a feature check. A feature check isn't very expensive, especially compared to writing more than a kilobyte, but it does mean ~2x the generated code because we need a fallback strategy.

Perhaps we could use rep stos as the fallback, so it will be fewer code to generate. SSE-only machines may get slower, but most machines, especially the ones performance sensitive users care, probably have AVX.