Web Assembly

[jerome]

and this recent topic, directly from the WASM project itself, may also help :  https://github.com/WebAssembly/design/issues/1231

[jerome]

Hi guys,

Here's my first real WASM test : http://jerome.bousquie.fr/BJS/test/SPSWasm/spsWasm.html

Caution before clicking on the link : it's a very big SPS with 40K solid particles, this could freeze your browser. I'll report more precisely about this experiment here :

About WASM itself :

I generated the WASM bytecode from some code ported from TS to AS, AssemblyScript . If the logic is quite simple to port from TS to AS (because the syntax is almost the same, just add strong types like "f32", "u32" instead of "number"), the shared memory access (shared between the JS main program and the WASM module) is really complex and painful. Indeed, WASM knows only very basic numeric types only : i32, u32, f32, f64, etc and nothing about more complex structures like strings, arrays, objects. It's really low level and we have to deal with pointers and offset to pick/store the data at the byte level directly in the memory.

Note also that there's no garbage collector. This means that creating any "object" (array, instance of a class, each time we type the word "new", etc) in our logic will require to manually free the dynamically allocated memory to prevent memory leaks. Moreover WASM doesn't provide any math library, so no trigonometry at all (sine, cosine, tan, everything required for 3D computations actually), so we have to implement by ourselves, say, the function sine.

In brief, for a developer coming from a productive high level language, despite the help of the easy syntax of AS, it's a jump back in the past because the way to code it right looks more like some the C or the assembly way. Indeed, the first version of this code, very TS-like, very twice slower than this more low-leveled published version.

You can get the AS source here : http://jerome.bousquie.fr/BJS/test/SPSWasm/index.ts    [EDITED]

That's said, what about the gain ?

Here are different versions and the FPS in my Chrome :

Legacy SPS   - 8 fps : http://jerome.bousquie.fr/BJS/test/spsReference.html 

Reference Buffer SPS - 7 fps :  http://jerome.bousquie.fr/BJS/test/spsBuffer.html  fun to see that now the legacy SPS what has been optimized is faster than the lighter buffered one

WASM SPS -  31 fps : http://jerome.bousquie.fr/BJS/test/SPSWasm/spsWasm.html  it's the port of the Buffer SPS in AS

perfs gain = x 4.42    ... not that bad, finally

[Janx]

Very interesting. I get 45 FPS with the WASM SPS vs 12 with the legacy SPS. I would like to see the code, but this link  http://jerome.bousquie.fr/BJS/test/index.ts gives me a 404.

[jerome]

Sorry, the right link is http://jerome.bousquie.fr/BJS/test/SPSWasm/index.ts

In order to compare things with equity, I measured the elapsed time on the part ported to WASM only (because some of the time is elapsed in the user logic that remains in the JS loop anyway : how do the particles move ?). This part is the engine, what the SPS does for you under the hood whatever the logic you implement :

Buffer SPS internal computations :  86-92 ms per frame

Wasm SPS internal computations : 18 ms

The isolated real gain of WASM is then a x5.44 speed increase.  That's exactly what I expected from this port. Why ? because this is the expected average ratio between dynamically and statically typed languages in general (from x5 up to x20).

 

[jerome]

For those who might be curios about I finally achieve the painful data exchange between JS and the WASM module, here's the explanation directly in the AssemblyScript Github repo :  https://github.com/AssemblyScript/assemblyscript/issues/263#issuecomment-422786251

I wouldn't have succeeded without the AS contributors help. Thanks to them.

https://github.com/AssemblyScript/assemblyscript/issues/263#issuecomment-422786251

https://github.com/AssemblyScript/assemblyscript/issues/263#issuecomment-422786251

[The Leftover]

Dang dude!  You stuck it through.  Slings, arrows and coral reefs.  Impressive.