WASM3 v0.5 Released With Claims To Be The Fastest WebAssembly Interpreter

[phoronix]

Phoronix: WASM3 v0.5 Released With Claims To Be The Fastest WebAssembly Interpreter

WASM3 v0.5 has been released for this project that calls itself the fastest WebAssembly interpreter as well as the most universal WebAssembly run-time. WASM3 runs across all major operating systems and can also run on WebAssembly itself / self-hosting, run on MCUs, and run in other environments...

https://www.phoronix.com/scan.php?page=news_item&px=WASM3-v0.5-Released

[ddriver]

No way!

It runs a 1993 game?

That's amazing!

[kpedersen]

Doom engine is compiled to WASI, then Python3, pygame, pywasm3 and numpy are used to create a suitable execution environment.

Certainly not a "light" tech stack. You can certainly tell these guys are web developers. Why not chuck some Java, Node.js, Python2, Perl and Ruby in the mix too. Make a proper deployment mess

I also think Emscripten is a great tool but it really is frustrating that for ~1% of the functionality it provides above standard Clang/LLVM, it drags in Node.js, Python and Java.

[LubosD]

It would be really cool if Chrome's wasm VM became faster.

My code is currently 85% slower under Chrome than native. "Not great, not terrible".

[ddriver]

It would be really cool if Chrome's wasm VM became faster.

It is even cooler if you reduce dependencies, bloat and abstractions, rather than increasing them.

Funny thing is a lot of that additional bloat is introduced to address issues that arise from... bloat. Yeah, I am sure that will solve it.

Hey, let's run native applications in a browser that runs in a virtual machine that runs in a browser. Just because.

[kpedersen]

Doom engine is compiled to WASI, then Python3, pygame, pywasm3 and numpy are used to create a suitable execution environment.

Certainly not a "light" tech stack. You can really tell these guys are web developers. Why not chuck some Java, Node.js, Python2, Perl and Ruby in the mix too. Make a proper deployment mess

I also think Emscripten is a great tool but it really is frustrating that for ~1% of the functionality it provides above standard Clang/LLVM, it drags in Node.js, Python and Java.

(Posted again, I think the forums ate my last)

[LubosD]

I also think Emscripten is a great tool but it really is frustrating that for ~1% of the functionality it provides above standard Clang/LLVM, it drags in Node.js, Python and Java.

Emscripten is a heavy hammer designed for quickly "porting" a GUI app or game to the browser so you can show off how cool wasm is.

Now when you want to actually develop something for wasm in C++ - which is not a GUI app, but e.g. just a computations library - and you wish to throw in some multithreading, you will encounter some really stupid crap that you have to work around.

I can't wait for WASI to support multithreading and then finally wish Emscripten good bye.

[kpedersen]

Emscripten is a heavy hammer designed for quickly "porting" a GUI app or game to the browser so you can show off how cool wasm is.

For me it is more to just stick to C and C++ as a platform for middleware and just about everything else rather than having to flit around with every single domain specific scripting language. There simply is not time for that kind of rewrite. SDL1 and SDL2 really are handy to target.

However even at this point I don't really go with WASM. I stick to emitting the slightly older ASM.js to support those pesky older platforms (in particular mobile browsers that tend to rarely update). I will probably end up sticking to Emscripten until ASM.js is no longer necessary.

Edit: Before Emscripten, I actually used this instead (it used to be called Alchemy back then): https://github.com/adobe-flash/crossbridge
So Emscripten was really just the logical evolution. Will be quite exciting once clang/llvm emitting WASM bytecode by itself is an option with a suitable standard library.

[tildearrow]

It would be really cool if Chrome's wasm VM became faster.

My code is currently 85% slower under Chrome than native. "Not great, not terrible".

85%?! And here I thought it was 50%...

[LubosD]

85%?! And here I thought it was 50%...

Just to clarify - by saying 85% slower I mean the computations take 85% more time.