6 ms·

Much as I miss the Beeb, this is completely irrelevant.

midgetjones 9y ago
I'd be inclined to agree. Unless the point was not to show off, but that a 30 year-old computer is as fast as the bleeding edge in browser rendering technology.
- kranner 9y ago
  An unoptimised implementation says nothing about what WASM is eventually capable of. This is an apples-to-oranges comparison unless the WASM app were optimised for speed. (Also parent mentions a 40x25 display on the BBC Micro). Game of Life implementations are ideal case studies for optimisation after Michael Abrash's graphics programming columns.
  - flukus 9y ago
    Unoptimised code says a lot, it's an indication of what we can expect of real world apps that will be mostly or entirely unoptimised. It's like theoretical vs real world java performance, in limited and optimised benchmarks it might produce fast code, but in real projects it doesn't. 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.
    - kranner 9y ago
      > Unoptimised code says a lot, it's an indication of what we can expect of real world apps that will be mostly or entirely unoptimised. 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.
- Sharlin 9y ago
  Given that this [1] runs easily at solid 60fps on Chrome, a pure software rasterizer written in pure JavaScript with some basic optimizations, I'm pretty sure that webasm is can do at least as well. The Beeb is not capable of anything remotely like that. https://jsfiddle.net/Sharlin/9w26necy/52/ https://jsfiddle.net/Sharlin/9w26necy/52/
  - midgetjones 9y ago
    Well sure, but can you play Granny's Garden in Chrome?
ABNWZ 9y ago
... I don't share your sentiment at all. I find this relevant to the subject matter as he is, albeit indirectly, mentioning the performance of WASM. I would be surprised if you got the same performance using just plain old js on the hardware he is referencing.
- DamonHD 9y ago
  I'm not sure that you could load JS on the BBC Micro! 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.
- tomxor 9y ago
  The JS/WASM may be limited to 60FPS if it is being forced to draw every frame, in which case it has to wait for the browser, it may be much faster. 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.
amelius 9y ago
Why? It gives a perspective on the resulting performance.

I'd be inclined to agree. Unless the point was not to show off, but that a 30 year-old computer is as fast as the bleeding edge in browser rendering technology.

kranner 9y ago
An unoptimised implementation says nothing about what WASM is eventually capable of. This is an apples-to-oranges comparison unless the WASM app were optimised for speed. (Also parent mentions a 40x25 display on the BBC Micro). Game of Life implementations are ideal case studies for optimisation after Michael Abrash's graphics programming columns.
- flukus 9y ago
  Unoptimised code says a lot, it's an indication of what we can expect of real world apps that will be mostly or entirely unoptimised. It's like theoretical vs real world java performance, in limited and optimised benchmarks it might produce fast code, but in real projects it doesn't. 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.
  - kranner 9y ago
    > Unoptimised code says a lot, it's an indication of what we can expect of real world apps that will be mostly or entirely unoptimised. 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.
Sharlin 9y ago
Given that this [1] runs easily at solid 60fps on Chrome, a pure software rasterizer written in pure JavaScript with some basic optimizations, I'm pretty sure that webasm is can do at least as well. The Beeb is not capable of anything remotely like that. https://jsfiddle.net/Sharlin/9w26necy/52/ https://jsfiddle.net/Sharlin/9w26necy/52/
- midgetjones 9y ago
  Well sure, but can you play Granny's Garden in Chrome?

ABNWZ 9y ago

... I don't share your sentiment at all. I find this relevant to the subject matter as he is, albeit indirectly, mentioning the performance of WASM. I would be surprised if you got the same performance using just plain old js on the hardware he is referencing.

DamonHD 9y ago
I'm not sure that you could load JS on the BBC Micro! 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.
tomxor 9y ago
The JS/WASM may be limited to 60FPS if it is being forced to draw every frame, in which case it has to wait for the browser, it may be much faster. 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.

amelius 9y ago

Why? It gives a perspective on the resulting performance.