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

21–30 of 130 posts

Re: A first look at WebAssembly performance

#21

Post by flohofwoe »

simooooo wrote: post #12

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

Probably yes ;) Javascript is already compiled down to machine code for quite a while. And if the code is very 'static' (like asm.js) the JS engine will leave the code alone, and the garbage collector will be inactive. Performance between asm.js and WebAssembly is pretty much the identical at the moment, with 10% to 20% disadvantage vs native there isn't that much room for drastic improvement. I think WebAssembly will mostly bring improvements for 64-bit integer operations and vector math, but for average integer and floating point code, JS is already very fast.

Re: A first look at WebAssembly performance

#22

Post by amelius »

flohofwoe wrote: post #21
simooooo wrote: post #12

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

Probably yes ;) Javascript is already compiled down to machine code for quite a while. And if the code is very 'static' (like asm.js) the JS engine will leave the code alone, and the garbage collector will be inactive. Performance between asm.js and WebAssembly is pretty much the identical at the moment, with 10% to 20% disadvantage vs native there isn't that much room for drastic improvement. I think WebAssembly wil…

I think the biggest advantage of WASM will be predictable performance. E.g., no sudden garbage collector pauses, and more predictable across different browser brands (eventually).

Re: A first look at WebAssembly performance

#23

Post by strainer »

krausest wrote: post #18
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)…

That would be great. Just send me a pull request!

Well I got it completing and its taking about 35% longer than the 'original' method. I do expect index lookups to be faster than property lookups so believe there must be some inefficiency in my hasty refactoring.

Or there might be an issue with there being only 5 bodies in the test. Im a bit puzzled.

Ill send the code later in the day.

Re: A first look at WebAssembly performance

#24

Post by benjismith »

simooooo wrote: post #12

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

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 WebAssembly never had anything to do with performance.

Re: A first look at WebAssembly performance

#25

Post by Derbasti »

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 between the two.

I, for one, hope that WebAssembly will enable, say, Lua as a first class citizen on the web.

Re: A first look at WebAssembly performance

#27

Post by pmontra »

benjismith wrote: post #24
simooooo wrote: post #12

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

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?

Re: A first look at WebAssembly performance

#28

Post by rnikhil275 »

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…

Lua is already on the web. Check out the Sailor MVC Framework.

Re: A first look at WebAssembly performance

#29

Post by singularity2001 »

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…

>> "but if they are possible with WebAssembly, they are also be possible with plain JavaScript"

only with asm.js not with 'plain' JavaScript

EDIT: sorry I completely missed the content of the OP! Wow

Re: A first look at WebAssembly performance

#30

Post by singularity2001 »

flohofwoe wrote: post #21
simooooo wrote: post #12

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

Probably yes ;) Javascript is already compiled down to machine code for quite a while. And if the code is very 'static' (like asm.js) the JS engine will leave the code alone, and the garbage collector will be inactive. Performance between asm.js and WebAssembly is pretty much the identical at the moment, with 10% to 20% disadvantage vs native there isn't that much room for drastic improvement. I think WebAssembly wil…

>> Javascript is already compiled down to machine code for quite a while.

oh really?

Post reply on HN