Nice!
With a BBC Micro (6502, 1MHz) I was able to achieve about the same FPS (I was genlocked for UK PAL TV transmission so either 25FPS or 50FPS) but only for a 40x25 grid, using 6502 assembler embedded in BASIC!
With a BBC Micro (6502, 1MHz) I was able to achieve about the same FPS (I was genlocked for UK PAL TV transmission so either 25FPS or 50FPS) but only for a 40x25 grid, using 6502 assembler embedded in BASIC!
Lots of branches in the inner loop, like range check.
https://github.com/blaze33/way-of-life/blob/master/src/js/wa...
No point to benchmark "Hello, World!"s.
Game of Life implementations are ideal case studies for optimisation after Michael Abrash's graphics programming columns.
And that's the best case, there are already people in this thread talking about compiling python to web assembly, any performance improvements over the current state of the web are going to be pissed away immediately.
Maybe but not in this kind of performance-sensitive application that spends most of its time in a tight inner loop. Then it really comes down to how optimised that inner loop is.
The point as that for something running safely virtualised (and standardised) in a random browser and on a much larger canvas, the WASM implementation is very impressive.
CA are great fun to optimise, i've found ways to make them very fast in JS alone, by using pure state machine method with TypedArrays and sliding window algorithm. When letting it skip frames (only drawing when a frame is available) it can go far beyond generations per second... when you get to larger grids the ultimate optimisation is to use FFT, but on smaller ones there is too much overhead and sliding window is way faster.
Algorithmic optimisation is always better, but this demo works for the purpose of showing basic WASM compilation which was the authors intent, there may be an order of magnitude improvement if a different implementation was used.