3 ms·
FWIW, the performance of my emulators [0] (mostly integer bit twiddling code written in 'portable C') is pretty much identical in the browser and natively compi
by flohofwoe 3y ago
FWIW, the performance of my emulators [0] (mostly integer bit twiddling code written in 'portable C') is pretty much identical in the browser and natively compiled version (within around 25% of each other).
Of course one could go farther by using cpu- and compiler-specific optimizations (for instance SIMD intrinsics), but some of those are also portable to WASM. In general, memory layout optimizations translate directly to the WASM linear heap, and that's by far the most important performance factor before it makes sense to look into platform-specific optimizations.
[0] https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/
- jcelerier 3y ago... 25% ? I'd sell my soul for a computer that's single-thread 25% faster than what we have right now
- flohofwoe 3y agoAny code in interactive applications needs to have wiggle room to allow for a much greater variation in performance than 25% anyway, WASM will just "hit the wall" slightly earlier. If macOS decides to run your code on an efficiency core or a mobile device throttles the clock to avoid overheating, you'll lose a lot more performance than just 25%. Or if some users have a lower end device, or you use different compilers for different target platforms, or a new hardware exploit hits and the mitigation results in a general performance loss. The only situation where such 'wiggle room' isn't required is when you completely control the environment your code runs in, but in this case you don't need runtime portability nor safety, and thus WASM wouldn't make sense in the first place.