Item — HN Reader

"Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications."

So did they mean only GUI-less client applications?

EDIT: also e.g. this source https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... makes it clear that porting e.g. C++ GUI applications is an intended feature, not just a silly idea of some hobbyists.

1 comments

Browser API calls add 1us of overhead. If your code is conscious of this, then it won’t be a problem. Much of the thought process behind react is to update the dom as little as possible, because it usually takes a while to repaint. Similarly, your WASM code will have this small overhead, but even 1000 calls is just 1ms. Regardless, there is still much more performance gains to be had by WASM-compatible languages when providing computationally expensive features.

My favorite example is Rapier http://rapier.rs/, check out the 3D demos. It blows every JS physics engine out of the water, and it’s using Conrod, a native gui library which has a webgl backend.

Looks like a nice physics engine, but I wouldn't say it blows JS engines out of the water performance wise. They are surprisingly fast these days.

Ammo js: http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.ht...

Ammo wasm: http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.wa...

They can be faster, but it is still insane how fast JS interpreters have become. So for smaller application it might be ok to stay in JS land.

Thanks for the link. I tried the cubes 3d demo which takes about 45 seconds on my laptop until no cube moves anymore (around step 590); probably not the expected performance; if I find time I will run the Rust version locally.

I tried the same thing and it took 4 seconds on my 8 year old computer.

Thanks for the info. My laptop has about the same age. Maybe you have the much faster graphics chip than my HP EliteBook.

Drawing a few boxes with webgl has nothing to do with a graphics card. This is about webasm which is single core performance.

From https://en.wikipedia.org/wiki/WebGL:

"WebGL is fully integrated with other web standards, allowing GPU-accelerated usage of physics and image processing and effects as part of the web page canvas"

So I would guess that when your graphics chip is faster than mine you get a higher performance.

These two things have nothing to do with each other.

This is a physics engine running on your CPU, not your GPU.

The webgl window is run with your GPU and is extremely simple. Drawing a few dozen boxes is something graphics cards from 22 years ago would have no problem with.

And yet the graphics are actually the performance bottleneck.

I tried that on a 4k monitor, and it ran quite slowly. I then made the window smaller, and it ran much faster. It's bottlenecked on the graphics, not on the physics engine.

I think that says a lot more about your combination of software and hardware than webasm.

If someone says "webasm is slow, this demo took 45 seconds to run" and you say "it ran slow for me when I made the window so big that between my browser's webgl implementation, my gpu drivers and my graphics card, a hundred cubes make everything run at 1/10th the speed" what point is that making?