[lewing]

The emscripten libc (6.0.2 as pinned here) implements memmove with musl's memmove.c: non-overlapping copies are forwarded to memcpy (which uses memory.copy for n >= 512), but overlapping copies always run a scalar loop, regardless of -mbulk-memory. SpanHelpers.Memmove sends overlapping buffers to the memmove QCall, which was bound directly to that libc symbol, so overlapping Span<T>.CopyTo/Array.Copy on CoreCLR wasm was far slower than on the Mono interpreter (whose jiterpreter emits memory.copy). In the Mono interpreter vs CoreCLR composite R2R comparison, Span<Char>.CopyToOverlap(Size: 3000) was ~20x and Span<Byte>.CopyToOverlap(Size: 3000) ~13.6x slower on CoreCLR.

This binds the browser memmove QCall to a small wrapper around __builtin_memmove, which lowers to memory.copy with -mbulk-memory. The wrapper has a TODO to remove it once the emsdk includes emscripten-core/emscripten#27654 (memmove via __builtin_wasm_memory_copy, in emscripten 6.0.10+); the bump is tracked in #136012. wasi-sdk 34.0 is not affected (its memmove already has a memory.copy path), so the change is browser-only.

Measurements: composite R2R browser-wasm publish (PublishReadyToRun=true), Release, run on node, overlapping byte CopyTo (dest = src + 1), ns per call:

Size	Before	After
1024	292	29
3000	782	44
6000	1520	74
12000	3030	136

The non-overlapping control is unchanged (~43 ns at 3000, ~125 ns at 6000). The benchmark is the Span<T>.CopyToOverlap shape from dotnet/performance. These were measured on a single arm64 macOS machine and I did not run Mono on the same machine.

Validated by building clr.native and clr+libs+packs for browser-wasm Release (confirming the object contains memory.copy) and running the R2R publish benchmark above. I did not run the library or runtime test suites, and did not build or test WASI.

Related to #136012

Note

This PR description was generated with AI assistance (GitHub Copilot) on behalf of @lewing.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

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

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[jkotas]

Are the limits at

runtime/src/libraries/System.Private.CoreLib/src/System/SpanHelpers.ByteMemOps.cs

Lines 24 to 26 in 44253fe

	private const nuint MemmoveNativeThreshold = 2048;
	#endif
	private const nuint ZeroMemoryNativeThreshold = 1024;

right for wasm? I guess the break-even point will be lower for wasm.

[lewing]

Are the limits at ... right for wasm? I guess the break-even point will be lower for wasm.

Lower, but not by much. Measured on browser-wasm R2R (V8, arm64 macOS) in one binary; overlapping copies always take the QCall, so they give the native cost at every size (ns, managed vs memory.copy): 128 B 8 vs 18, 512 B 14.5 vs 22, 1024 B 24 vs 25, 1536 B 34 vs 30, 2048 B 44 vs 34. Break-even is ~1024; the QCall's ~10 ns fixed cost keeps it from going lower.

• f2a6e2c lowers MemmoveNativeThreshold to 1024 for CoreCLR wasm. 1536 B now takes ~29.5 ns and 2048 B ~34 ns; sizes up to 1024 are unchanged. Mono is excluded since its memmove icall goes through a different path that I haven't measured.
• ZeroMemoryNativeThreshold (1024) is already at break-even, but only once memset uses memory.fill: the pinned emscripten libc memset is musl's scalar loop and is 1.4-1.7x slower than memory.fill for 1-4 KB. a0eba6f adds the same wrapper for memset. Upstream fixed it in [libc] Always use __builtin_wasm_memory_fill in memset emscripten-core/emscripten#27656, which is also in 6.0.10+, so both wrappers go away with the emsdk bump (Bump emsdk to >= 6.0.10 to pick up memory.copy-based memmove (overlapping Span.CopyTo is 4-5x slower on CoreCLR wasm) #136012).

System.Memory.Tests pass on browser composite R2R with these changes (52,254 run, 0 failed).

Note

This comment was generated with AI assistance (GitHub Copilot) on behalf of @lewing.

[radekdoulik]

/cc @BrzVlad