I tried re-implementing this in WASM.. it's slower than both versions?! https://observablehq.com/d/ce811886e1071d69

(maybe the WASM version would be faster if I made it work on a typed array - it could be that the overhead of passing data between WASM and JS is the real slowdown)

hi @Job That's surprising right? I've been playing with WASM thinking it could be faster than JS, have you read this post from Colin Eberhardt https://blog.scottlogic.com/2017/10/17/wasm-mandelbrot.html#performance , in his experiment JS was just 25% slower than native.

If I'm reading the benchmark correctly, the WASM function is about half the speed of native JS, which is in the ballpark of what I'd expect since the function is small (= emphasizes the calling overhead of WASM), uses simple bitwise operations (which ought to optimize pretty well in native JS), and since it doesn't trigger SIMD operations in WASM. It might bring out WASM's strengths to ask it to compute n random numbers in a single wasm loop, e.g. `rand_wasm(destinationTypedArray, 1e7)`. At any rate, my sense is that WASM has lots of incredible strengths, but computing things faster in small functions is often not one of them. (bonus points if you can manage to break the loop into chunks of four or something and trigger simd operations.)

Yeah, I guess the issue might be also be an inability to inline WASM functions. So one option to get the most out of this would be to rewrite the demo to use putImageData instead of fillRect, which would let us do the visual noise rendering inside WASM as well. Might give that a go, but the benchmark would be very different