Do we need a memcpy opcode?

[juj]

In a number of game engines I've been optimizing and benchmarking, interestingly the performance of memcpy() does show up relatively high in profiles. (~2%-5% of total execution time)

I did a recent optimization to memcpy in Emscripten, and added some benchmarks. See emscripten-core/emscripten#4127 (especially http://clb.demon.fi/emcc/memcpy_test/results.html)

The result there was that asm.js+SIMD memcpys are at worst ~3x slower than native at aligned copy sizes around 4k - 16k bytes, and Wasm memcpys are at worst ~6x slower than native at aligned copy sizes around the same size.

It is not immediately obvious to me how much we can close this gap e.g. by further optimizing the memcpy implementation in Emscripten, and optimizing Wasm implementations in browsers, which raises the question of whether it would make sense to have a memcpy (and probably as extension, memset) opcode directly in wasm?

Currently in Emscripten very large memcpys round trip to HEAP8.set(), but it has a drawback of generating temporary garbage.

[juj]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1254573

[lukewagner]

(Copying over from the bugzilla comment) I think it would make sense to add a page-unit mempcy operator to our finer-grained control over memory list. Having page units means wasm can assume the caller is doing all the small-memcpy() optimizations (inlining, unrolling, peeling, etc) and then simply call out to the C++ memcpy() (which presumably then does all the fancy stuff).

[jfbastien]

Dup #236 ?

[lukewagner]

Hah, 2015... seems so long ago. (It'd be nice to get it listed in FutureFeatures.md, though.)