Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A first look at WebAssembly performance

stefankrause.net

Post reply on HN
Print view View original

41–50 of 130 posts

Re: A first look at WebAssembly performance

#41

Post by Matthias247 »

pmontra wrote: post #27
benjismith wrote: post #24

Earlier quoted context omitted.

Well remember, WebAssembly just a different representation format for the same instruction set, executed by the underlying virtual machine (v8, spidermonkey, etc). So you should expect to see much of a performance difference. The main benefit of WebAssembly is so that we can write code using our favorite languages (not just javascript!) and compile to a common binary format the browser understands. The objectives of…

Are there DOM bindings for languages other than JavaScript or is WebAssembly only for backend/webservices?

As far as I understand you can call JS APIs from WebAssembly, which means you use the already available DOM APIs. I don't know exactly what the calling convention from WASM to JS looks like, but I guess it's specified somewhere.

Re: A first look at WebAssembly performance

#42

Post by hrjet »

krausest wrote: post #17
simooooo wrote: post #12

Am I the only one that was expecting web assembly to be like 10x JS speeds?

I also hoped to see a bigger improvement, but it turned out that Javascript is already very fast for nbody. Maybe I should have picked a well known numeric benchmark where Javascript is still far behind - any suggestions for that? Or are the Javascript VMs already too good for numeric benchmarks?

You can try increasing `N` in the nbody problem, and also measuring the memory overhead.

You could also try one of the hashing / crypto algorithms in JS. They should involve a lot of integer arithmetic that should make WebAssembly stand out.

More tips:

* for performance measurement, setup the benchmark so that JS run takes atleast 30 seconds. (Increase N, etc)

* close all other applications and tabs

* If you have linux, set the CPU governor to performance

* Measure the CPU temperature and make sure you let the CPU cool down between runs. In modern CPUs, the cores get throttled automatically when they reach a certain temperature.

Re: A first look at WebAssembly performance

#43

Post by fmap »

Derbasti wrote: post #25

The way I understand it, WebAssembly is all about the size of the binary and parsing overhead. Or, at a higher level, about enabling a level playing field between more languages than just JavaScript. Speed improvements from a common runtime and bytecode are certainly welcome, but if they are possible with WebAssembly, they are also be possible with plain JavaScript, and therefore shouldn't be visible in a comparison…

JavaScript is JIT compiled, it has to be parsed, typechecked, interpreted and eventually compiled. WebAssembly is parsed and then translated to machine code (with a much simpler compilation pipeline).

Typical JavaScript VMs have a lot of fast paths for small scripts which also benefits small benchmarks like this. For more realistic workloads, parsing and compiling takes a significant amount of time and you could skip (almost) all of it by precompiling to WebAssembly (not at the moment, since you can't generate JavaScript objects from WebAssembly yet, but that'll happen eventually).

JavaScript in particular also has the problem that its semantics is an utterly horrifying mess... This forces the generated code to be very conservative and include a lot of dynamic checks and escape hatches to the interpreter. If anything, the situation is worse than with Lua, and let me remind you that LuaJIT doesn't actually compile said "escape hatches" because of code size. There are just that many of them.

Re: A first look at WebAssembly performance

#44

Post by strainer »

crocodileJS wrote: post #39
strainer wrote: post #14

I think there is no js version implemented which accesses the bodies parameters like this: x = body.x[body_index] I expect this should be much faster than accessing them like this: x = body.[body_index].x Because the latter requires pointer-from-property calculation for every single values access (which must be somehow optimised) The former just requires pointer-from-property calculation for every array (not element)…

You must mean: x = bodies_x[body_index] versus x = bodies[body_index].x The "issue" with the nbody benchmark from the benchmarks game is that there's only four bodies, making this SOA-style approach have little payoff. It would be great if you could do such a test, but with a significantly larger amount of bodies.

I do mean body.x[body_index], body.y[body_index], etc as:

body={ x:[] ,y:[] ,z:[] ,vx:[] ,vy:[] ,vz:[] ,mass:[] }

I find this is running 20% faster than the fastest on my chrome browser (an old version) but is slightly slower on firefox, but catches up a bit with 11 bodies.

I expect it could run faster yet by crunching the code up more and maybe removing objects altogether, but i made few changes as possible just to compare the difference in addressing.

There is also function "offsetMomentum" which tweaks the suns movement according to momentum of the planets, it seems very extraneous to me, gravitational influence should surely be sufficient in itself regarding conservation of momentum. I suspect that function is more likely a catch for large errors which can result from point grav bodies getting to close to each other.

Re: A first look at WebAssembly performance

#45

Post by MereInterest »

simooooo wrote: post #12

Am I the only one that was expecting web assembly to be like 10x JS speeds?

As a comparison, I wrote an identical program in both C++ and JavaScript. It was doing repeated calls to a kd-tree, and was CPU-limited in both cases. The JavaScript version was slower, but only by a factor of 5-7 or so. I was rather surprised, because I was expecting a factor of 100-500, as I get with C++/CPython.

I don't expect WebAssembly to improve much on the speed, because it is already pretty fast.

Re: A first look at WebAssembly performance

#46

Post by TheCycoONE »

Matthias247 wrote: post #41
pmontra wrote: post #27

Earlier quoted context omitted.

Are there DOM bindings for languages other than JavaScript or is WebAssembly only for backend/webservices?

As far as I understand you can call JS APIs from WebAssembly, which means you use the already available DOM APIs. I don't know exactly what the calling convention from WASM to JS looks like, but I guess it's specified somewhere.

There are a few, none of them optimal for DOM manipulation yet because they all involve calling javascript. There is plans to add wasm dom hooks eventually. https://kripken.github.io/emscripten-site/docs/porting/conne...

Re: A first look at WebAssembly performance

#47

Post by Veedrac »

MereInterest wrote: post #45
simooooo wrote: post #12

Am I the only one that was expecting web assembly to be like 10x JS speeds?

As a comparison, I wrote an identical program in both C++ and JavaScript. It was doing repeated calls to a kd-tree, and was CPU-limited in both cases. The JavaScript version was slower, but only by a factor of 5-7 or so. I was rather surprised, because I was expecting a factor of 100-500, as I get with C++/CPython. I don't expect WebAssembly to improve much on the speed, because it is already pretty fast.

Javascript engines are fairly speedy compared to CPython; not only are they industrial-grade JITs (as opposed to CPython being a naive interpreter), but JS is an easier language to optimize. Further, WebAssembly has overhead.

5-7x difference seems reasonable to me.

Re: A first look at WebAssembly performance

#48

Post by CryZe »

simooooo wrote: post #12

Am I the only one that was expecting web assembly to be like 10x JS speeds?

I've written all my Advent of Code 2016 puzzles in Rust that I've then compiled to asm.js and WebAssembly and both asm.js and WebAssembly always outperformed the idiomatic JavaScript solutions by a factor of 10x and sometimes even up to 40x. Firefox has the best asm.js and wasm support, with Edge being the second fastest browser and Chrome being the slowest (I only tested those 3). WebAssembly is always faster by about 10% in all the browsers than asm.js. However asm.js supports vector instructions and wasm doesn't. So when your inner loops are vectorized your asm.js even runs as fast in Firefox as the same code compiled as native code.

Re: A first look at WebAssembly performance

#49

Post by matt4077 »

I'm surprised Chrome doesn't manage to be the fasted in any of these tests, considering the focus Google has put on performance and the resources I thought they were devoting to Chrome.

It appears as if they'd come out ahead on average, but not by a definitive margin. Especially surprised by FF which I thought had somewhat dropped the ball (and/or simply been overrun once Google's business objectives aligned with the users' interests).

Re: A first look at WebAssembly performance

#50

Post by TeMPOraL »

hacker_9 wrote: post #37
Derbasti wrote: post #25

The way I understand it, WebAssembly is all about the size of the binary and parsing overhead. Or, at a higher level, about enabling a level playing field between more languages than just JavaScript. Speed improvements from a common runtime and bytecode are certainly welcome, but if they are possible with WebAssembly, they are also be possible with plain JavaScript, and therefore shouldn't be visible in a comparison…

> Speed improvements from a common runtime and bytecode are certainly welcome, but if they are possible with WebAssembly, they are also be possible with plain JavaScript Nope, a static language will execute faster than a dynamic language, because the runtime knows precisely what type everything is and how much space to allocate. Additionally no faffing around with dictionaries for dynamic types. Currently JS engines…

> Edit: Additionally, browsers will finally consume less power, CPU time and memory, because the execution runtime process will be so streamlined.

Don't worry, the software industry (and adtech) will find new cool ways to bloat the websites so that their resource usage will be back to usual high, while offered features stay more-less the same. That's pretty much how desktop, mobile and web all have been evolving so far.

Post reply on HN