WebAssembly and Rust: performance analysis | Hacker News Reader

WebAssembly and Rust: performance analysis

polaris64.net

95 pointsfulafel20 comments

The WebGL implementation is kinda cheating - shaders use single precision floats and sloppy --ffast-math style optimizations, whereas the JS and WASM versions use double precision and strict IEEE floating point rules. Hence why the WebGL version produces noticeably different results to the others.

It would be interesting to replace f64 with f32 in the Rust code and see how much difference that makes. Unfortunately there's no --ffast-math in Rust yet AFAIK.

Related: Mozilla recently used WASM-via-Rust to reimplement the core of its source-map JS lib (with millions of downloads per day, so many of you are probably already using it) and concluded that the new version is "5.89 times faster" on real-world data: https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...

This tickles me wonderfully. WASM has felt like a promising way to do... things... faster. But a real sign of it finally "arriving" is that it's being used by lots of people who won't even know it, other than the significant and free performance boost.

https://news.ycombinator.com/item?id=16178658

Ah thanks, I missed that discussion. :)

Not only in JS, I got decent performance with Rust's regex engine compiled to WASM then compiled to the JVM: https://github.com/cretz/asmble/tree/master/examples/rust-re.... And that's without any extreme optimization on the JVM side.

I haven't checked the source code but generally calls between runtime boundaries are costly (JS to WebAssembly) so it's critical to do all the work in WebAssembly and just return a complete solution at the end.

Yes. Until [1], WASM in the browser is to be used like we use a GPU : crazy fast, but expensive calls and memory to/from JS

[1]: https://github.com/WebAssembly/host-bindings/blob/master/pro...

As far as I know every function call in and out of WebAssembly or asm.js must run through a foreign function interface (FFI)to translate between different binary interfaces. This can be very costly. Mapping and copying of data is necessary. And don't forget the garbage collector.

I dont quite understand this result.

The last frame took 0.012999999999738065ms to render.

Is there a timer with that resolution? Is this an average over 1000 frames? Doesn't seem like it.

Plus, there is no such thing that I know of that is a WebGL program. WebGL is a library that JS or WebAssembly program use to get access to the GPU. So I guess what he is saying is that be moving the calculations to the GPU he got a huge speed up. What's the news there?

That's looks like a floating point error. Don't read into it too much.

From the Results section you can see what the author thinks of the main takeaways:

"Currently, running the demonstration in the latest versions of both Chrome and Firefox on Linux, with an integrated Intel GPU, shows that the WebGL version is the fastest, as expected. Interestingly however, the performance of the WebAssembly version matches the plain JavaScript version almost exactly!"

The WebGL example is measuring how long it takes to send the rendering request to the GPU, not the actual computation time. The correct way to measure GPU execution time is to use timer queries.

The render function ends with a call to gl.finish(), which should block until the GPU actually finishes rendering. It's a crude way to measure performance but it's probably good enough for this.

Until the GPU driver _says_ it has finished rendering.

Been developing WebGL for years. I've never seen any difference in performance with gl.finish() and without vsync. I would expect some difference because the JS code wouldn't be running in parallel with gl.finish().

The only way I have been able to measure performance is to look at the FPS without vsync (chrome --disable-gpu-vsync).

WebGL isn't only fast -- running his tests on my browser it's x1000 times faster than JS or WebAssembly.

It's also visibly worse quality than JS or WASM. It's not computing with the same resolution.

It looks identical on my devices and multiple browsers. Perhaps there is a problem with the webgl code on certain browsers or hardware?

Odd. I notice the difference clearly in both Chrome and Firefox. Intel Core i7 4790k, Nvidia GTX 1050Ti, Windows.

jsheard mentioned that the WebGL code is using single-precision floating point and some rough optimizations, while the JS and WASM are using double-precision floats and no such optimization. I wonder why you wouldn't see a difference if that's the case, since the result should be worse.

It is 1000 times faster, each point would compute its own value, and you have around 1000 GPU processors.

Reply on news.ycombinator.com