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

71–80 of 130 posts

Re: A first look at WebAssembly performance

#71

Post by flohofwoe »

jackmott wrote: post #63
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…

are you using SIMD in your c code? are you taking care to lay out memory for optimal cache locality? are you allocating memory too much? when the performance deltas are small you may not be fully leveraging C yet.

No SIMD support, there's no dynamic memory allocation happening at all, data layout should be mostly ok (the hottest data block is the RGBA8 framebuffer where video decoding goes to, and that's filled linearly).

Re: A first look at WebAssembly performance

#72

Post by Tunabrain »

joakleaf wrote: post #67
dreta wrote: post #34

Earlier quoted context omitted.

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…

That's a bold claim; Sure it is theoretically possible, to have two versions of the same C program take either 500ms or 8ms purely due to memory layout. But I would like to challenge you to actually do it! I.e. same number of calculations, on same amount of data and a factor of 60 run time difference, with only the memory layout as actual difference between the two implementations. Up for it?

Any entry level optimization course will make you implement something like that; do a matrix+matrix addition, but traverse it in row-major order in one program, and column-major in the other. If the matrix is big enough, you will easily get a 10x difference. For even larger sizes (once you thrash the TLB), you will get an additional factor.

You might not get up to 60, but this is just a simple matrix addition. Even just matrix multiplication might be enough to get a 60x difference just with optimizing for memory hierarchy. I expect that high-performance memory bound programs are more complex than matrix multiplication, so the parent comment's claim doesn't seem too unlikely to me.

Re: A first look at WebAssembly performance

#73

Post by pjc50 »

rasz_pl wrote: post #56
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

As the author says in sibling comment, impersonating a processor is much easier than making an accurate reproduction of period video and sound hardware.

Re: A first look at WebAssembly performance

#74

Post by joakleaf »

Tunabrain wrote: post #72
joakleaf wrote: post #67

Earlier quoted context omitted.

That's a bold claim; Sure it is theoretically possible, to have two versions of the same C program take either 500ms or 8ms purely due to memory layout. But I would like to challenge you to actually do it! I.e. same number of calculations, on same amount of data and a factor of 60 run time difference, with only the memory layout as actual difference between the two implementations. Up for it?

Any entry level optimization course will make you implement something like that; do a matrix+matrix addition, but traverse it in row-major order in one program, and column-major in the other. If the matrix is big enough, you will easily get a 10x difference. For even larger sizes (once you thrash the TLB), you will get an additional factor. You might not get up to 60, but this is just a simple matrix addition. Even j…

Sorry, I didn't mean to question it whether it is possible. I just think that a factor of 60 sounds tricky to achieve if we are just talking about RAM (no disk involved).

The first time I encountered this myself, was doing texture mapping on the 486 back in the mid 90s. Texels would be laid out by row, and the mapper would draw horizontally. Texture maps that would fit within the L1 cache would draw fine no matter which rotation they were drawn it.

However texture maps that were larger than the L1-cache, would be drawn fine as long as the texture map wasn't significantly rotated. But, if you rotated the polygon by 90 degrees you'd see a significant drop in frames per second, because you'd skip a while row between drawing each texel, which would effectively cause a lot of cache misses. OK, I didn't manage to explain that well, but I hope it is understable.

Obviously, I have encountered this many times since, in many variants (including disk read/write), and I definitely agree that a factor of 10 should be possible.

I guess, I am just wondering if the difference between RAM and L1 has reached a factor 60, and how easy it is to come up with something where the cache misses all the time, or if caches have become smarter.

Re: A first look at WebAssembly performance

#75

Post by sp332 »

rasz_pl wrote: post #56
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

Games use every little glitch and quirk of an architecture. Emulating a zillion edge cases on another architecture takes a lot of power. In 2011, someone finally made an accurate SNES emulator but it needed a 3GHz CPU. https://arstechnica.com/gaming/2011/08/accuracy-takes-power-...

Re: A first look at WebAssembly performance

#76

Post by igouy »

krausest wrote: post #16
emersonrsantos wrote: post #10

Earlier quoted context omitted.

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

http://benchmarksgame.alioth.debian.org/for-programming-lang...

Those charts show 300 runs of Java n-body #3.

Re: A first look at WebAssembly performance

#77

Post by FeepingCreature »

joakleaf wrote: post #74
Tunabrain wrote: post #72

Earlier quoted context omitted.

Any entry level optimization course will make you implement something like that; do a matrix+matrix addition, but traverse it in row-major order in one program, and column-major in the other. If the matrix is big enough, you will easily get a 10x difference. For even larger sizes (once you thrash the TLB), you will get an additional factor. You might not get up to 60, but this is just a simple matrix addition. Even j…

Sorry, I didn't mean to question it whether it is possible. I just think that a factor of 60 sounds tricky to achieve if we are just talking about RAM (no disk involved). The first time I encountered this myself, was doing texture mapping on the 486 back in the mid 90s. Texels would be laid out by row, and the mapper would draw horizontally. Texture maps that would fit within the L1 cache would draw fine no matter wh…

Googling puts RAM latency avoiding caches on modern processors at 40-60 cycles.

Re: A first look at WebAssembly performance

#78

Post by joakleaf »

FeepingCreature wrote: post #77
joakleaf wrote: post #74

Earlier quoted context omitted.

Sorry, I didn't mean to question it whether it is possible. I just think that a factor of 60 sounds tricky to achieve if we are just talking about RAM (no disk involved). The first time I encountered this myself, was doing texture mapping on the 486 back in the mid 90s. Texels would be laid out by row, and the mapper would draw horizontally. Texture maps that would fit within the L1 cache would draw fine no matter wh…

Googling puts RAM latency avoiding caches on modern processors at 40-60 cycles.

Exactly... Now, that alone could make it tricky to get a factor 60 difference.

Re: A first look at WebAssembly performance

#79

Post by rch »

hajile wrote: post #70
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…

> I, for one, hope that WebAssembly will enable, say, Lua as a first class citizen on the web. I can think of several languages I'd like to use on the web, but never really considered Lua. I'm curious. Why Lua?

Apart from general fitness for embedding and extending, I like the versatility of Lua tables:

https://www.lua.org/pil/3.6.html

In particular, to initialize a table to be used as a record:

    a = {x=0, y=0}
which is equivalent to:

    a = {}; a.x=0; a.y=0
and:

    a.x = nil -- removes field "x"
But I think Guido's right about 0-based indexing:

http://python-history.blogspot.com/2013/10/why-python-uses-0...

Re: A first look at WebAssembly performance

#80

Post by pacaro »

joakleaf wrote: post #78
FeepingCreature wrote: post #77

Earlier quoted context omitted.

Googling puts RAM latency avoiding caches on modern processors at 40-60 cycles.

Exactly... Now, that alone could make it tricky to get a factor 60 difference.

Write a simplistic O(N^3) algortihm

When N is 100, all fixed costs in the inner loop are multiplied by 1,000,000. So a nanosecond difference is now a millisecond. It's pretty easy to get worse than that by boneheaded data layout (row-major vs column-major is pretty common)

Post reply on HN