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

11–20 of 130 posts

Re: A first look at WebAssembly performance

#11

Post by flukus »

foota wrote: post #9
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.

I think that's almost certainly false. JIT'd java is almost certainly faster than bytecode interpreted java. edit: or do you mean that the overhead of applying optimizations and profiling outweigh the performance gains relative to compiling from something like c directly to machine code?

I mean the collection and application of the optimizations take up more CPU than the optimizations remove. This isn't JIT but real time optimizations (https://en.wikipedia.org/wiki/Adaptive_optimization) while the system is running.

Re: A first look at WebAssembly performance

#13

Post by szemet »

flukus wrote: post #8
foota wrote: post #5

Earlier quoted context omitted.

If you have dynamic data the best optimizations could change, and you can't feed the profile back to the compliler while the program is running. (Well... maybe in theory)

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 you the proper implementation - without per call indirection - or may even inline it.

If you code C++ in Java style then JVM will win - so the overhead of (runtime) profiling and applying optimizations not always greater

Re: A first look at WebAssembly performance

#14

Post by strainer »

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) involved in the nbody loops, the individual element|values are picked out by array addressing which is inherently much simpler than property access.

I've used this method for nbody physics. I can modify a test to it and push to the repo.

Re: A first look at WebAssembly performance

#16

Post by krausest »

emersonrsantos wrote: post #10
ktta wrote: post #7

Earlier quoted context omitted.

He does talk about the laptop he uses at the end of the post. >All tests were performed on a 2015 MacBook Pro, 2.5 GHz Intel Core i7, 16 GB 1600 MHz DDR3. For all tests the best of three runs was selected for the result.

But how do you disable CPU throttling on an intel macbook to do accurate benchmarks?

I didn't. I believe that is's better to run a few times and take the best run. I payed for the turbo mode CPU and I'd like to know the performance on my machine. There's a lot going on my machine, and even more when a browser is running. The only thing (besides running on a clean machine) one can do about it is to measure multiple runs. Three runs are maybe a bit to little for scientific results, but I considered them good enough for a casual benchmark.

Re: A first look at WebAssembly performance

#17

Post by krausest »

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?

Re: A first look at WebAssembly performance

#18

Post by krausest »

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!

Re: A first look at WebAssembly performance

#19

Post by rl3 »

richardwhiuk wrote: post #4
batmansmk wrote: post #3

Our benchmarks show amazing results... but not in speed. WebAssembly for us is about the size of the binary and the speed of parsing more than the speed of execution... A Javascript JIT with enough execution data can be even better than C in theory.

You could feed the profile data back into the C compiler in theory, so in practice, I think the C could always be faster.

This is called profile-guided optimization.[0] Slightly off-topic, but even Rust has it, courtesy of LLVM.[1]

It doesn't seem very popular unfortunately. Most web/tech companies are obsessive about capturing user interaction data for UX purposes, but it would be nice if that data could be fed back into a profile-guided optimizer.

In theory the compiled WebAssembly output would always be optimized for the latest usage trends, provided there were frequent builds. Depending on the product, it may even be possible to classify users into various high-level categories based on their behavior, and serve them a binary that's optimized for their specific use case. The latter's level of specificity probably wouldn't be worth it though.

[0] https://en.wikipedia.org/wiki/Profile-guided_optimization

[1] https://unhandledexpression.com/2016/04/14/using-llvm-pgo-in...

Re: A first look at WebAssembly performance

#20

Post by flohofwoe »

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% integer code, with a lot of 8- and 16-bit integer bit operations (shifting, masking, ...). No calls into the browser or operating system, and almost no calls into the CRT or C++ stdlib (may be a small memcpy here and there).

The performance differences for 'pure' C code between browser- and native-version are so small now that they are no longer relevant, at least for the use cases I encountered, or rather within the normal performance differences when running the code on a slightly different CPU.

Calling out into HTML5 APIs is a whole different topic though ;)

Post reply on HN