Exploring SIMD performance improvements in WebAssembly (2021)
1–10 of 25 posts
Re: Exploring SIMD performance improvements in WebAssembly (2021)
#2It looks promising! But fixed-width lanes don't seem too cross-platform? I don't just mean the v256 and v512 types that may become ubiquitous in a few years, but also things like optimizing for different L1 cache sizes, doing some operation macro-fusion on the SIMD unit, or directly supporting leading/trailing elements to reduce code size?
Re: Exploring SIMD performance improvements in WebAssembly (2021)
#3It looks promising! But fixed-width lanes don't seem too cross-platform? I don't just mean the v256 and v512 types that may become ubiquitous in a few years, but also things like optimizing for different L1 cache sizes, doing some operation macro-fusion on the SIMD unit, or directly supporting leading/trailing elements to reduce code size?
Thanks! Good points, I think in general the fixed-width "packed" SIMD ISAs have the downsides that you mentioned.
But it seems that WebAssembly doesn't have length-agnostic SIMD instructions yet. There is an open proposal to add this though: https://github.com/WebAssembly/flexible-vectors
Re: Exploring SIMD performance improvements in WebAssembly (2021)
#4It looks promising! But fixed-width lanes don't seem too cross-platform? I don't just mean the v256 and v512 types that may become ubiquitous in a few years, but also things like optimizing for different L1 cache sizes, doing some operation macro-fusion on the SIMD unit, or directly supporting leading/trailing elements to reduce code size?
In practice it's not possible to optimize "generally" for all possible target architectures your wasm will run on. You're going to optimize for x86-64 or ARM, and probably going to specifically optimize for modern intel, modern amd, or apple's m1. If you try to optimize for everything you're going to run into really painful tradeoffs and probably have mediocre performance on a bunch of architectures after a lot of hard work.
Re: Exploring SIMD performance improvements in WebAssembly (2021)
#5Did a similar test in plain C: https://godbolt.org/z/ffYcWhxz3
It's not quite the same: I've used an increment instead of zeroing, otherwise the entire benchmark gets optimized away. Still got just about the same result (3.7x speedup for 100 iterations), so wasm did good there. Actually, now that I think of it, SIMD code performance probably depends on good register allocation more than on any optimization.
Re: Exploring SIMD performance improvements in WebAssembly (2021)
#6It looks promising! But fixed-width lanes don't seem too cross-platform? I don't just mean the v256 and v512 types that may become ubiquitous in a few years, but also things like optimizing for different L1 cache sizes, doing some operation macro-fusion on the SIMD unit, or directly supporting leading/trailing elements to reduce code size?
In practice it's not possible to optimize "generally" for all possible target architectures your wasm will run on. You're going to optimize for x86-64 or ARM, and probably going to specifically optimize for modern intel, modern amd, or apple's m1. If you try to optimize for everything you're going to run into really painful tradeoffs and probably have mediocre performance on a bunch of architectures after a lot of ha…
Why not? Fixed-size SIMD architectures use mostly the same operations, so if you target SSE2 initially, the code should run just fine on NEON. A runtime that ships a JIT compiler also has the unique opportunity to further optimize SIMD code by using more lanes or limiting the working set to the host platform's L1 cache size. Even the AOT compilers like GCC or clang emulate platform-specific intrinsics using generic vector ones. This should count for something, no?
Re: Exploring SIMD performance improvements in WebAssembly (2021)
#7I wonder if the 4x performance boost of 128-bit SIMD over 32-bit would drop to 2x if WebAssembly added 64-bit registers/instructions.
Re: Exploring SIMD performance improvements in WebAssembly (2021)
#8I compared against native:
#define ITERATIONS 1000
int main()
{
const size_t BUFFER_SIZE = 64ul \* 1024 \* 1024;
__m128i\* data_buffer = (__m128i *)memalign(64, BUFFER_SIZE);
const __m128i all_ones = _mm_set1_epi8(0xFF);
for (size_t i = 0; i At higher number of iterations the C version converges on about 1.7 seconds per 1000, while the WASM version seems to remain the same at 4.2 secs per 1000. This leaves native 2.5x faster for this particular operation, on my machine.
Re: Exploring SIMD performance improvements in WebAssembly (2021)
#9I wonder if the 4x performance boost of 128-bit SIMD over 32-bit would drop to 2x if WebAssembly added 64-bit registers/instructions.
Webassembly has 64-bit locals and instructions.
Re: Exploring SIMD performance improvements in WebAssembly (2021)
#10Earlier quoted context omitted.
In practice it's not possible to optimize "generally" for all possible target architectures your wasm will run on. You're going to optimize for x86-64 or ARM, and probably going to specifically optimize for modern intel, modern amd, or apple's m1. If you try to optimize for everything you're going to run into really painful tradeoffs and probably have mediocre performance on a bunch of architectures after a lot of ha…
Why not? Fixed-size SIMD architectures use mostly the same operations, so if you target SSE2 initially, the code should run just fine on NEON. A runtime that ships a JIT compiler also has the unique opportunity to further optimize SIMD code by using more lanes or limiting the working set to the host platform's L1 cache size. Even the AOT compilers like GCC or clang emulate platform-specific intrinsics using generic v…
They are similar but not the same, for instance SSE has movemask, but NEON does not, so it gets emulated(slowly) when targeting that platform. The cross lane ops are different enough that you might need to rewrite for other platforms. And then you run into situations where an instruction is very fast on one architecture but horribly slow on another because its basically emulated.