I also found this which I'd like to try out later today: https://github.com/anowell/quasar
WebAssembly 101: A developer’s first steps
11–20 of 153 posts
Re: WebAssembly 101: A developer’s first steps
#12Nice! 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!
Looks like the code is pretty slow.
Lots of branches in the inner loop, like range check.
https://github.com/blaze33/way-of-life/blob/master/src/js/wa...
Re: WebAssembly 101: A developer’s first steps
#13Earlier quoted context omitted.
Much as I miss the Beeb, this is completely irrelevant.
... 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.
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.
Re: WebAssembly 101: A developer’s first steps
#14Earlier quoted context omitted.
Much as I miss the Beeb, this is completely irrelevant.
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.
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.
Re: WebAssembly 101: A developer’s first steps
#15Not very reassuring that two of the first steps are "copy and paste this stuff from stack overflow to make it work", without any explanation as to why it's needed.
Re: WebAssembly 101: A developer’s first steps
#16I hope they add support for garbage collected languages soon. I don't feel like going back to work with malloc and free after 20 years.
Re: WebAssembly 101: A developer’s first steps
#17Re: WebAssembly 101: A developer’s first steps
#18Earlier quoted context omitted.
Much as I miss the Beeb, this is completely irrelevant.
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.
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.
Re: WebAssembly 101: A developer’s first steps
#19I'm trying to use asm.js to port Python to JS as a shared library, which would allow us to load and run arbitrary CPython modules (compiled for JS) in the browser. I generate code using emscripten, which is also able to generate WASM (which I'm not using at the moment though).
My experience so far:
Emscripten is quite mature and compiles even very complex C/C++ code without complaining. Statically linking code works fine, while dynamically loading shared libraries is still a bit problematic it seems.
Here's the Github project btw, help is very welcome:
Re: WebAssembly 101: A developer’s first steps
#20Not very reassuring that two of the first steps are "copy and paste this stuff from stack overflow to make it work", without any explanation as to why it's needed.
Agreed. Setting up the environment with 0's seems like it should just be the sane default:
'env': {
'memoryBase': 0,
'tableBase': 0,
'memory': new WebAssembly.Memory({initial: 256}),
'table': new WebAssembly.Table({initial: 0, element: 'anyfunc'})
}