A first look at WebAssembly performance
stefankrause.net
A first look at WebAssembly performance
1–10 of 130 posts
Re: A first look at WebAssembly performance
#2These performance numbers are amazingly impressive considering we're talking about JavaScript vs. C.
Hopefully the various browser vendors can iron out some of the performance problems here and even things up better.
Re: A first look at WebAssembly performance
#3Our 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.
Re: A first look at WebAssembly performance
#4Our 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.
Re: A first look at WebAssembly performance
#5Our 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.
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)
Re: A first look at WebAssembly performance
#6How the author turned off speedstep on a macbook?
I assume he's using MacOS because of the Safari benchmark.
Re: A first look at WebAssembly performance
#7How the author turned off speedstep on a macbook? I assume he's using MacOS because of the Safari benchmark.
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.
Re: A first look at WebAssembly performance
#8Earlier quoted context omitted.
You could feed the profile data back into the C compiler in theory, so in practice, I think the C could always be faster.
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.
Re: A first look at WebAssembly performance
#9Earlier 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.
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?
Re: A first look at WebAssembly performance
#10How the author turned off speedstep on a macbook? I assume he's using MacOS because of the Safari benchmark.
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?