Sign in to follow this  
The Leftover

Web Assembly

Recommended Posts

Hi guys,

Here's my first real WASM test :

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 :    [EDITED]

That's said, what about the gain ?

Here are different versions and the FPS in my Chrome :

Legacy SPS   - 8 fps : 

Reference Buffer SPS - 7 fps :  fun to see that now the legacy SPS what has been optimized is faster than the lighter buffered one

WASM SPS -  31 fps :  it's the port of the Buffer SPS in AS

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

Share this post

Link to post
Share on other sites

Sorry, the right link is

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).


Share this post

Link to post
Share on other sites

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

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

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.