memcpy is much larger than Emscripten variant

[zeux]

trafficstars

I'm in the process of [experimentally] migrating some code that today gets compiled via Emscripten to wasi-sdk.

Doing size comparisons, for one of the reactors the Emscripten-compiled binary is significantly smaller:

decoder_emcc.wasm 6872 decoder_wasi.wasm 8365

Looking at the delta (1493 bytes), it looks like a lot of the delta comes down to the differences in sizes between memcpy (that this code needs, and using bulk-memory extension of Wasm isn't an option):

wasi memcpy: 1448 emcc memcpy: 518 delta 930 bytes

This is the change that optimized memcpy version in Emscripten: https://github.com/emscripten-core/emscripten/pull/7648 Would it be possible to implement something along these lines here?

[sunfishcode]

Yes, we could do something similar.

The Emscripten version seems to have fewer special cases for performance, so it's likely a codesize versus speed tradeoff. We could let the user pick which tradeoff they want to make at link time, with an option like -lsmall-memcpy or -lfast-memcpy or so. If anyone's interested in working on this, the first step is to write the C code to do the memcpy. Then we can figure out how best to incorporate it into the wasi-libc build.

The Emscripten code calls into JavaScript to do HEAPU8.set() for large copies, which we won't be able to do. We could add a WASI API to do memory copying, or we could just wait for bulk-memory to be more widely available. That said, this is just an optimization, so this could be a separate step.

[zeux]

Emscripten does have a stand-alone version that doesn’t call out to JS for large copies.