Conversation
|
Sounds good! I'll take a look tonight |
|
@bluss With When I unrolled the loop only if If supporting a byte-precise matmul variant is also a main goal (so people would use |
|
Thanks for testing! I don't have any goals myself for wasm, so it's actually better if you as a user decide this. Is your use case only for +simd128 so far? (+relaxed-simd seems to be held back by lack of Safari support?) Changing unrolling only for +relaxed-simd seems like the only way forward (or not changing it at all). |
Not really so far, but I think it's good to change unrolling only for +relaxed-simd if it's not a big burden. |
Just small changes - use a shuffle to splat a lane. One less intrinsic, but compiler already ensured the result was the same, so no effect in practice. Unrolling was investigated here. On a laptop m4, unrolling had no effect; on laptop i5, it had a small positive effect. Keep it simple and avoid extra code for unrolling if its effect is small.
|
Decision is to skip unrolling since it has no benefit on my m4 system (I benchmarked the sensitivity to that now), keep it simple. Now the PR just remains as a benchmark tool improvement, refactoring and opt-in relaxed-simd benefit. |
Add support for +relaxed-simd in wasm, which increases performance and should degrade gracefully when not available. relaxed-simd adds a fused multiply-add instruction, except that it doesn't guarantee fused operation; it can also be implemented by multiply then add (which leaves us where we started).
--wasmin the benchmark runner, selectable features (simd128 with or without relaxed)Small refactoring in the wasm loop.
Unrolling the loop by 2 was explored - with just +simd128 it is a negative, with +simd128,+relaxed-simd it helps a bit on my intel laptop and helps nothing on my apple m4 laptop. Decision: no unrolling for now, keep it simple.