Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Great release with many welcome features. As a nit, I'm rather disappointed at the inclusion of fixed-size SIMD (128-bit wide) instead of adaptive SIMD instructions letting the compiler maximize SIMD width depending on host capabilities, similar to how ARM SVE works.


Personally I prefer fixed-size SIMD mainly because it enables more usages than usual vector instructions while vector instructions can be rather trivially lowered to fixed-size SIMD instructions. I'd call them as "opportunistic" usages, because those are perfectly fine without SIMD or vector but only get vectorized due to the relatively small size of SIMD registers. Those usages are significant enough that I see them as useful even with the presence of vector instructions.


If you have variable length SIMD, you can always treat them as fixed-size SIMD types.

New x86 processor don't executes 128-bit SIMD, the vecto ALUs are all wider now and 128 and 256-bit instructions have the same throughput and latency.

Also, do you have an example for such "opportunistic" usages?

I suppose mainly things the SLP vectorizer can usually do already (in compiled languages, I'm not sure how good the JIT is these days).

I worry that we now may end up in a world, where "hand optimized SIMD" in WASM ends up slower than autovectorization, because you can't use the wider SIMD instructions and leave 2x (zen4) to 4x (zen5) of the performance on the table.


> Also, do you have an example for such "opportunistic" usages?

The simplest example would be copying a small number of bytes (like, copying structs). Vector instructions generally have a higher setup cost, like setting so it can't really be used for this purpose. Maybe future vector instructions have no such caveats and can be used as like SIMD, but AFAIK it's not yet the case even for RISC-V's V extension.


The size of the vector width really isn't as important as the general design of the instructions themselves. It's pretty trivially easy to extend the number of lanes and vector width with the right design. This is separate from the problem of "what is the best size for the particular host machine I'm running on", but that's something we've already been handling in various ways for a while, without needing wholly new instruction set designs.


premature optimization is the root of all evil and this SIMD mess could have been implemented so much more elegantly if they just followed the general variable size wasm flexible vector proposal

https://github.com/WebAssembly/flexible-vectors


What happened there? Looks like it was created 10 years ago (is wasm even that old?) And has barely been updated in the last year


Announced 2015 and before that we were experimenting in asm.js




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: