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

81–90 of 130 posts

Re: A first look at WebAssembly performance

#81

Post by Coding_Cat »

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?

I'll take that challenge. Here's how to do it, with a little bit of sneaky interpretation of 'memory layout':

have an algorithm which takes a large struct S and looks at a subset Sf to determine what to do with S, for some value of Sf use all of S, otherwise skip it. (e.g. when distance between 2 particles Now have a very low pass-rate for the filter so that total time ~= time taken to read all of Sf. Make Sf a single byte and S >= 64 bytes (page size if you really want to beat it).

And now compare array-of-struct vs struct-of-array ;). You should see ~64x performance difference in the assymptotic case.

AoS will use one byte per cacheline read. SoA will use 64 bytes per cacheline. if you're memory bound this will translate to an almost 64x speed difference. There are other ways to achieve the same effect but that is the gist of getting 64x performance. using 1 byte vs 64. if you want to go really crazy, use a single bit and a bitfield array for the SoA. If you use a bitfield the passing chance doesn't have to be that low.

I happened to have to present on AoS vs SoA today so I have a less extreme benchmark to show the difference (~16x because it filters over 32 bit ints)

http://imgur.com/a/HuXFR

Re: A first look at WebAssembly performance

#82

Post by gjjrfcbugxbhf »

strainer wrote: post #44
crocodileJS wrote: post #39

Earlier quoted context omitted.

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.

I do mean body.x[body_index], body.y[body_index], etc as: body={ x:[] ,y:[] ,z:[] ,vx:[] ,vy:[] ,vz:[] ,mass:[] } I find this is running 20% faster than the fastest on my chrome browser (an old version) but is slightly slower on firefox, but catches up a bit with 11 bodies. I expect it could run faster yet by crunching the code up more and maybe removing objects altogether, but i made few changes as possible just to…

Floating point errors accumulate quite quickly when dt is small it could be a smoothing function.

Re: A first look at WebAssembly performance

#83

Post by xxs »

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…

>>Languages like Java and JavaScript don't let you lay data out

You can do enough magic in Java, if need be. It's just not easy and you'd using arrays (not objects) or direct byteBuffers

---- Btw the entire test runs in L1, so memory layout irrelevant. It's just not a good test.

Re: A first look at WebAssembly performance

#84

Post by curyous »

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.

A JIT faster than C? I thought in theory it would always have to be slower because you have the overhead of the JITing. Also, isn't compiling C to native, the best you can hope for anyway? What could be faster than that, except for asm?

Re: A first look at WebAssembly performance

#85

Post by pcwalton »

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…

> 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.

asm.js is effectively a static language.

Re: A first look at WebAssembly performance

#86

Post by pcwalton »

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

> Because the latter requires pointer-from-property calculation for every single values access (which must be somehow optimised)

Global value numbering (GVN) should be trivially able to do this.

Re: A first look at WebAssembly performance

#87

Post by rasz_pl »

flohofwoe wrote: post #68
rasz_pl wrote: post #56

Earlier quoted context omitted.

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

He, do it better then ;) The CPU emulation alone is about 300x faster then an original Z80 (runs at 1.2 GHz on the same MBP), most performance is currently burned in the CPC video emulation (way more expensive then the CPU). The CPU and memory system is quite optimized, the other systems not so much.

afaik CPC video is very basic, pretty much a raw MC6845 crtc. No sprites, no blitters, no dma. What is giving you so much problems performance wise?

Re: A first look at WebAssembly performance

#88

Post by tyoverby »

curyous wrote: post #84
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.

A JIT faster than C? I thought in theory it would always have to be slower because you have the overhead of the JITing. Also, isn't compiling C to native, the best you can hope for anyway? What could be faster than that, except for asm?

Typical benchmarks for jitted languages like javascript don't include the jitting in their numbers.

Jits can beat C in performance in situations where understanding how the program behaves at runtime influences code generation optimizations.

Re: A first look at WebAssembly performance

#89

Post by rasz_pl »

pjc50 wrote: post #73
rasz_pl wrote: post #56

Earlier quoted context omitted.

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.

This depends entirely on hardware. You can run good emulation of 8 bit computers (spectrum, c64, cpc) at ~hundreds to thousands the original speed using emulators written in C. Using emulator that barely reaches x10 factor as a performance benchmark for webassembly is questionable.

Re: A first look at WebAssembly performance

#90

Post by DannyBee »

Just wanted to say thanks for being so thorough in describing the compilation flags, versions, etc.

It's really refreshing :)

You also just may want to s/gcc/clang/, none of the gcc compile commands you are running are using gcc, they are all clang/llvm. Apple just aliased the gcc binary to clang on macs.

Post reply on HN