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

91–100 of 130 posts

Re: A first look at WebAssembly performance

#91

Post by 13years »

matt4077 wrote: post #49

I'm surprised Chrome doesn't manage to be the fasted in any of these tests, considering the focus Google has put on performance and the resources I thought they were devoting to Chrome. It appears as if they'd come out ahead on average, but not by a definitive margin. Especially surprised by FF which I thought had somewhat dropped the ball (and/or simply been overrun once Google's business objectives aligned with the…

There is a lot more to Chrome than just the JS engine. Much of Chrome's performance has been in areas that improve the total browsing experience.

Re: A first look at WebAssembly performance

#92

Post by [deleted] »

xxs wrote: post #83
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…

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

[deleted]

Re: A first look at WebAssembly performance

#93

Post by flohofwoe »

rasz_pl wrote: post #87
flohofwoe wrote: post #68

Earlier quoted context omitted.

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?

The video config can be changed by the CPU in the middle of a scanline so you can't decode an entire scanline in a tight loop but need to run video decoding interleaved with the CPU (currently it's ticked after an entire CPU instruction though, not per cycle), and every tick of the video system needs to figure out all the decoding parameters again, because they might have changed since the last tick (and demo-scene demos use this mid-scanline-stuff a lot).

Also the display isn't driven directly by the 6845, HSYNC and VSYNC go through the Gate Array where a few ticks of latency is added, the same is true for the interrupt request that happens every 52 scanlines.

On top of that the CPC has an extra funky pixel bit pattern (http://cpctech.cpc-live.com/docs/graphics.html)

I haven't spent any time at all yet optimizing the video system though, for instance the pixel decoding might benefit from lookup tables. I first want to get it accurate enough for demo-scene gfx demos, and than will take care of performance.

Re: A first look at WebAssembly performance

#94

Post by Klathmon »

crocodileJS wrote: post #40
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…

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

What's amazing is that in some engines, if the JIT can determine that you are within the bounds of the array, it can disable those checks for the duration of the loop.

So something like for (x = 0; x < arr.length; x++) {...} can run at pretty much the same speed as C code.

Re: A first look at WebAssembly performance

#95

Post by Klathmon »

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…

That's not really true, as JS engines will already compile things with the assumption that the types won't change and "bail out" if they do.

So if you can "hint" to the JIT that a variable is an integer, and it will stay an integer, then it will not only "unbox" it and treat it as an integer, it will compile the code very similar to how a static language would.

In asm.js, this is done by using little "tricks" of JS to hint to the compiler that something is (for example) an integer by appending `|0` to it.

So there really shouldn't be any major difference between "static language -> webasm" and "JS -> webasm" if the JS is written with performance in mind.

In practice you'll probably see greater performance from a static language simply because you "can't" violate those rules so there doesn't need to be really any "guarding" or checking, but you aren't looking at anything like a magnitude speed increase here, it'd be incremental in most cases.

Re: A first look at WebAssembly performance

#96

Post by flohofwoe »

rasz_pl wrote: post #89
pjc50 wrote: post #73

Earlier quoted context omitted.

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.

That's a pretty bold claim considering that (for instance) MAME's CPC emulation eats 25% of one CPU core (checked with vsync enabled). MAME might not be the fastest because they do a lot of the inter-chip-communication via function pointers, but they're also not idling around and the CPC emulation is quite accurate AFAIK. If you can point me to an emulator that's hundreds or thousands of times faster I'd really like to take a look, might steal some ideas ;)

Re: A first look at WebAssembly performance

#97

Post by ZenoArrow »

simooooo wrote: post #12

Am I the only one that was expecting web assembly to be like 10x JS speeds?

Worth remembering this is an early version of WebAssembly that is semantically similar to ASM.JS. Further performance improvements are very likely, can see some of the planned improvements here:

https://github.com/WebAssembly/design/blob/master/FutureFeat...

Also, we're unlikely to see 10x improvements over JS. Based on the benchmarks I've seen, JS isn't 10x slower than C.

Re: A first look at WebAssembly performance

#98

Post by Sean1708 »

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.

I've always wondered what C running on a JIT would be like. As far as I'm aware all the modern JIT languages are quite high level and do a lot more than C to begin with, so it would be interesting to see if you could eek out even more speed from C using a JIT.

Re: A first look at WebAssembly performance

#99

Post by sqeaky »

Coding_Cat wrote: post #81
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?

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

So you can write code that is 64x times slower when you specifically optimize for a slowdown. Cool.

Can you run that in web assembly and get the same slowdown. If so most of the same things that allow C/C++ to faster than other languages on systems will also allow them to be faster in the browser.

Re: A first look at WebAssembly performance

#100

Post by icefox »

CryZe wrote: post #48
simooooo wrote: post #12

Am I the only one that was expecting web assembly to be like 10x JS speeds?

I've written all my Advent of Code 2016 puzzles in Rust that I've then compiled to asm.js and WebAssembly and both asm.js and WebAssembly always outperformed the idiomatic JavaScript solutions by a factor of 10x and sometimes even up to 40x. Firefox has the best asm.js and wasm support, with Edge being the second fastest browser and Chrome being the slowest (I only tested those 3). WebAssembly is always faster by abo…

Do you have a link to your puzzles or perhaps a blog entry with a more full write up of your findings? There are not too many examples like this in the wild yet and another data point would be interesting.
Post reply on HN