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

31–40 of 130 posts

Re: A first look at WebAssembly performance

#31

Post by Vogtinator »

szemet wrote: post #13
flukus wrote: post #8

Earlier quoted context omitted.

The JVM has been capable of this for a while. I think the overhead of profiling and applying optimizations has always been greater than any efficiency gains.

'the overhead of profiling and applying optimizations has always been greater than any efficiency gains.' Not necessarily, especially if you explicitly rely on them. For example in C++ you deliberately have to avoid overusing virtual functions if you don't want the overhead. In Java, virtual functions are the default, and you usually don't care: if you call them a lot (e.g. in a tight loop) JVM will adaptively give y…

G++ is able to optimize virtual calls to non-virtual calls in most cases (speculative devirtualization) by adding quick checks into the code (like if(obj->vtable == Class::vtable) Class:virtualMethod(obj);) which the JVM would do as well.

So if G++ is able to tell the code paths leading to the virtual call, it does the same optimization as the JVM.

Re: A first look at WebAssembly performance

#33

Post by etiene »

rnikhil275 wrote: post #28
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.

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!

Re: A first look at WebAssembly performance

#34

Post by dreta »

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 how you lay things out in memory.

Re: A first look at WebAssembly performance

#35

Post by pjmlp »

Vogtinator wrote: post #31
szemet wrote: post #13

Earlier quoted context omitted.

'the overhead of profiling and applying optimizations has always been greater than any efficiency gains.' Not necessarily, especially if you explicitly rely on them. For example in C++ you deliberately have to avoid overusing virtual functions if you don't want the overhead. In Java, virtual functions are the default, and you usually don't care: if you call them a lot (e.g. in a tight loop) JVM will adaptively give y…

G++ is able to optimize virtual calls to non-virtual calls in most cases (speculative devirtualization) by adding quick checks into the code (like if(obj->vtable == Class::vtable) Class:virtualMethod(obj);) which the JVM would do as well. So if G++ is able to tell the code paths leading to the virtual call, it does the same optimization as the JVM.

g++ cannot do that across dynamic libraries. It needs to see the source code at compile time.

This is where JIT wins, as it can do that with binary deployed code.

Re: A first look at WebAssembly performance

#36

Post by crocodileJS »

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 doesn't have the same type information as WASM, also it lacks a native 64-bit integer. The JIT can do some type inference to use integers internally in some cases, but it's not optimal.

Predicting what sort of Javascript turns into what kind of native code on different JIT implementations is far from simple, too.

Even if in theory, an equivalent result should be possible in some cases, it's unrealistic to expect that in practice.

Re: A first look at WebAssembly performance

#37

Post by hacker_9 »

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 will have to figure out the types dynamically at runtime, but even then can't always be sure so have to keep to slower dictionary lookups.

Once we have a static language -> webasm, it should execute an order of a magnitude faster than JS -> webasm.

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

Re: A first look at WebAssembly performance

#38

Post by [deleted] »

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…

[deleted]

Re: A first look at WebAssembly performance

#39

Post by crocodileJS »

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.

Re: A first look at WebAssembly performance

#40

Post by crocodileJS »

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…

You actually can lay things out in memory using Typed Arrays.

There's some overhead to reads/writes though (there is memory safety, after all).

Post reply on HN