Enable SIMD by default?

[kripken]

Probably a little early given the state of browser support, but eventually we may want to do this. This would allow the autovectorizer to do things, even without explicit SIMD in the source files.

Looking at our benchmark suite, many benchmarks change size by less than 1%, some growing and some shrinking. A few change by larger amounts: base64 is 9% larger, lzma 7%, memops 3%, skinning 2%, while one shrinks by a lot: poppler by 7%. The last is actually the most realistic codebase, so I'm not sure what the average size change would be.

Only three benchmarks change in timing: skinning is 11% faster (makes sense, as it is a highly-vectorizable loop, and I guess the autovectorizer does well there), poppler is 7% faster (this surprised me but I double-checked), and zlib is 4% faster (ditto). No benchmark gets worse.

Overall there is no clear benefit/loss in size, and a few things speed up nicely, so this seems useful.

I also saw no test failures among the benchmarks. cc @dschuff who had some ideas on testing.

[lindell]

One reason not to do it is that SIMD instructions are not automatically converted to non SIMD instructions for users with CPUs that does not support (the right type of) SIMD. Even if WASM SIMD within the browser is supported.

https://source.chromium.org/chromium/chromium/src/+/main:v8/src/wasm/function-body-decoder.cc;l=96;drc=db569cd7847d479358bd391a18b2c28393803333

[kripken]

Thanks @lindell , good to know! We should definitely wait until browsers have good software fallbacks here.

[dschuff]

It looks like real SIMD is used for any CPU that supports SSSE3, which goes back to 2006. I wonder if we have any data on how many devices that really is.

[dschuff]

(Also, given that the number of devices is likely really small, I doubt that there is going to be a lot of work put in by engines to improve scalar fallback for the base SIMD proposal).

[sbc100]

This recently came up as part of our llvm-libc experimentation. Specifically llvm-libc's math function can take advantage of at leave FMA, but maybe other SIMD instructions. CC @google-yfyang

@kripken did you look into recompiling libc / libc++ etc with simd enabled too? I don't if there are any places there that could benefit.

[sbc100]

One thing to consider if we do enable this by default is how to handle sysroot issue. Do we:

1. Build all the sysroot libraries with SIMD enabled then add a lowering pass in binaryen (this is what we have done for more recent features).
2. Build a separate non-SIMD sysroot (currently we only do this for LTO, wasm64 and PIC).

[kripken]

@sbc100 good point, I just compiled with -msimd128, so only benchmark code itself was optimized with SIMD. I'm not sure if we have good benchmark code to stress libc/libc++, actually - we may need new benchmarks for the sysroot.