Add implementation of emscripten_memcpy_big based on bulk memory.

[sbc100]

These new functions live in libbulkmemory which only gets included if bulk memory is enabled (either via -mbulk-memory directly or indirectly via `-pthread).

benchmark results for benchmark.test_memcpy_1mb:

 v8:                       mean: 1.666
 v8-bulkmemory:            mean: 1.598
 v8-standalone-bulkmemory: mean: 1.576
 v8-standalone:            mean: 3.197

Here we can see the that when bulk memory is enabled its at least as fast if not faster than the JS version.

v8-standalone doesn't have emscripten_memcpy_big at all is is much slower, as expected. By adding -mbulk-memory the standalone version becomes just as fast as the non-standalone.

[haberman]

If bulk memory is available, why can't memcpy() and memset() use memory.copy and memory.fill exclusively? Why does emscripten_memcpy_big() need to exist at all in that case?

This code seems to be written with an assumption that the bulk memory operations have some kind of overhead that makes them only worthwhile for copies/fills of greater than 512 bytes. Is this true?

[sbc100]

If bulk memory is available, why can't memcpy() and memset() use memory.copy and memory.fill exclusively? Why does emscripten_memcpy_big() need to exist at all in that case?

This code seems to be written with an assumption that the bulk memory operations have some kind of overhead that makes them only worthwhile for copies/fills of greater than 512 bytes. Is this true?

I think you could well be correct and we might just want to completely remove the traditional __musl_memcpy when bulk memory is available.

The code that this was replacing involved calling out the JavaScript which certain had/has a non-zero overhead. We would probably want measure imperially weather memory.copy and memory.fill are faster or not for small copies, but it seems likely to me that there would have the same or better performance costs.

Do you have a particular reason to want this change? For example, is the cost of including __musl_memcpy concerning you?

[haberman]

Do you have a particular reason to want this change? For example, is the cost of including __musl_memcpy concerning you?

I am looking at a profile where __memcpy() (and __musl_memset() to a lesser extent) are significant costs, and I am hoping that using memory.copy and memory.fill would speed up my benchmark.

I don't know of a way to test this theory. Do you know of any way to force memcpy() to compile to memory.copy? I tried using __builtin_memcpy(), but oddly that still seems to call the __memcpy().

[sbc100]

The simplest way to do that would probably be to just remove the if (n >= 512) { check from memcpy.c, and then rebuild libc (either via ./embuilder build libc --force or ./emcc --clear-cache (to force all libraries to be rebuilt).