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

51–60 of 130 posts

Re: A first look at WebAssembly performance

#51

Post by majewsky »

TeMPOraL wrote: post #50
hacker_9 wrote: post #37

Earlier quoted context omitted.

> 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 f…

This can also be seen the other way around. Given the speed at which websites pile on unnecessary shit, just imagine how websites would perform if browser vendors weren't busy optimizing all day long.

Re: A first look at WebAssembly performance

#52

Post by rnikhil275 »

etiene wrote: post #33
rnikhil275 wrote: post #28

Earlier quoted context omitted.

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

Sailor author here. They probably mean on the front-end! :) For that we have Starlight ( http://starlight.paulcuth.me.uk ), which I use on Sailor as well. Very excited for the day we can run Lua natively on the browser!

Yes. You are correct. I totally misunderstood the context.

Re: A first look at WebAssembly performance

#53

Post by vbezhenar »

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…

> The main benefit of WebAssembly is so that we can write code using our favorite languages

JavaScript is already common format that browser understands and there are implementations for a lot of languages translating them to JavaScript. So WebAssembly definitely is about performance, because using other languages is already solved problem.

Re: A first look at WebAssembly performance

#54

Post by TeMPOraL »

majewsky wrote: post #51
TeMPOraL wrote: post #50

Earlier quoted context omitted.

> 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 f…

This can also be seen the other way around. Given the speed at which websites pile on unnecessary shit, just imagine how websites would perform if browser vendors weren't busy optimizing all day long.

That only matters if browser vendors stay ahead of the bloat curve (which I'm not so sure). Otherwise, one could say that for given performance point of the system (hardware platform + browser), there's a set level of bloat software sticks at, making the perceived performance constant.

Re: A first look at WebAssembly performance

#55

Post by flohofwoe »

dreta wrote: post #34
flohofwoe wrote: post #20

The C vs Firefox results are about the same that I'm seeing in my 8-bit emulator ( http://floooh.github.io/virtualkc/ ). For the Amstrad CPC (currently the most expensive system) on my 2.8GHz Core i5 MBP I'm seeing about 1.3 to 1.5 ms 'emulator time' per 16.6ms frame for the WASM/asm.js version on FF Nightly, and for the native version (clang -O3) about 1.2 to 1.4ms. This 'core emulator loop' is pretty much 100% inte…

Languages like Java and JavaScript don't let you lay data out in memory directly, nor do they give you much on control over how memory is accessed, so any performance benchmark involving C is entirely superficial. I can write 2 programs in C, both which iterate over some amount of elements and perform the same calculations on the same amount of data, and have one take 500ms and the other take 8s. It's all a matter of…

Emscripten uses a TypedArray for the C heap in asm.js which has the exactly same data layout as if the C code is compiled natively, this gives you (more or less) the same performance advantages for properly arranged data as native code.

Re: A first look at WebAssembly performance

#56

Post by rasz_pl »

flohofwoe wrote: post #20

The C vs Firefox results are about the same that I'm seeing in my 8-bit emulator ( http://floooh.github.io/virtualkc/ ). For the Amstrad CPC (currently the most expensive system) on my 2.8GHz Core i5 MBP I'm seeing about 1.3 to 1.5 ms 'emulator time' per 16.6ms frame for the WASM/asm.js version on FF Nightly, and for the native version (clang -O3) about 1.2 to 1.4ms. This 'core emulator loop' is pretty much 100% inte…

Wait. You emulate 3.5MHz machine on 2.8GHz Core i5, reach 10 the speed of original (1.3 to 1.5 ms 'emulator time' per 16.6ms) and therefore proclaim success? :o

Re: A first look at WebAssembly performance

#57

Post by icebraining »

matt4077 wrote: post #49

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…

Mozilla has done a great job of keeping up; they created some benchmarks to keep track of how well they're doing:

https://arewefastyet.com/

https://areweslimyet.com/

Re: A first look at WebAssembly performance

#59

Post by Ajedi32 »

exabrial wrote: post #58

I really want to like web assembly, but every time I read about it I SMH. We already have a bunch of great runtimes, compilers, and opcodes. I hate to see the effort duplicated yet again. Or maybe I'm missing something obvious?

> We already have a bunch of great runtimes, compilers, and opcodes.

I'm confused. Are you suggesting we, for example, use the JVM for this instead? WASM is being designed specifically with the web in mind, and has a lot of design goals which just weren't a concern for other runtimes. See: http://webassembly.org/docs/high-level-goals/

Re: A first look at WebAssembly performance

#60

Post by exabrial »

Ajedi32 wrote: post #59
exabrial wrote: post #58

I really want to like web assembly, but every time I read about it I SMH. We already have a bunch of great runtimes, compilers, and opcodes. I hate to see the effort duplicated yet again. Or maybe I'm missing something obvious?

> We already have a bunch of great runtimes, compilers, and opcodes. I'm confused. Are you suggesting we, for example, use the JVM for this instead? WASM is being designed specifically with the web in mind, and has a lot of design goals which just weren't a concern for other runtimes. See: http://webassembly.org/docs/high-level-goals/

Well not exactly, but I feel like the JVM, LLVM, parrot, CLR, or any one of those that have well defined opcodes could be leveraged instead of producing something entirely new. There's quite a bit of investment in those projects... Does that make more sense what I was trying to say?
Post reply on HN