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

61–70 of 130 posts

Re: A first look at WebAssembly performance

#61

Post by Ajedi32 »

exabrial wrote: post #60
Ajedi32 wrote: post #59

Earlier quoted context omitted.

> We already have a bunch of great runtimes, compilers, and opcodes. I'm confused. Are you suggesting we, for example, use the JVM for this instead? WASM is being designed specifically with the web in mind, and has a lot of design goals which just weren't a concern for other runtimes. See: http://webassembly.org/docs/high-level-goals/

Well not exactly, but I feel like the JVM, LLVM, parrot, CLR, or any one of those that have well defined opcodes could be leveraged instead of producing something entirely new. There's quite a bit of investment in those projects... Does that make more sense what I was trying to say?

They actually have that question in their FAQ: https://github.com/WebAssembly/design/blob/master/FAQ.md#why...

Re: A first look at WebAssembly performance

#62

Post by wyldfire »

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…

SoA vs AoS, see also [1] [2].

[1] https://software.intel.com/sites/default/files/article/39227...

[2] https://en.wikipedia.org/wiki/AOS_and_SOA

Re: A first look at WebAssembly performance

#63

Post by jackmott »

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.

Re: A first look at WebAssembly performance

#64

Post by exabrial »

Ajedi32 wrote: post #61
exabrial wrote: post #60

Earlier quoted context omitted.

Well not exactly, but I feel like the JVM, LLVM, parrot, CLR, or any one of those that have well defined opcodes could be leveraged instead of producing something entirely new. There's quite a bit of investment in those projects... Does that make more sense what I was trying to say?

They actually have that question in their FAQ: https://github.com/WebAssembly/design/blob/master/FAQ.md#why...

I guess that particular case makes sense. Straight LLVM IR would probably be a security risk anyway unless they built a fairly solid verifier.

Re: A first look at WebAssembly performance

#65

Post by wyldfire »

simooooo wrote: post #12

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

The promise that WASM holds IMO is for portability, not (merely) performance. How cool is it that I could write a game or application or library in C/C++/Rust/golang/swift/etc and expect it to be able to run on any modern CPU but also a browser?

Re: A first look at WebAssembly performance

#66

Post by exDM69 »

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…

> WebAssembly is all about the size of the binary and parsing overhead.

I don't think this is a good assessment.

WebAssembly needs to pass through a complete compiler backend before it can be executed.

WASM needs to be parsed, an in-memory representation is produced (probably LLVM IR), data flow and control flow graphs generated, a whole bunch of optimizations take place after which normal instruction selection, scheduling and register allocation and assembly take place.

This task is comparable in complexity to a JavaScript interpreter with a JIT compiler. However, JavaScript engines have optimized for a fast startup where the interpreter quickly starts running the program (while JIT'ing and optimizing in the background).

WASM has (or should have) two motivators: enabling near-native performance and allowing other languages to be compiled and executed in a browser. Based on this article, there's still a long way to go with performance. Most browser APIs are not accessible from WASM without some wrappers, so there's still work to be done before other languages become a viable replacement for JS.

Re: A first look at WebAssembly performance

#67

Post by joakleaf »

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…

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?

Re: A first look at WebAssembly performance

#68

Post by flohofwoe »

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

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.

Re: A first look at WebAssembly performance

#69

Post by n00b101 »

exabrial wrote: post #60
Ajedi32 wrote: post #59

Earlier quoted context omitted.

> We already have a bunch of great runtimes, compilers, and opcodes. I'm confused. Are you suggesting we, for example, use the JVM for this instead? WASM is being designed specifically with the web in mind, and has a lot of design goals which just weren't a concern for other runtimes. See: http://webassembly.org/docs/high-level-goals/

Well not exactly, but I feel like the JVM, LLVM, parrot, CLR, or any one of those that have well defined opcodes could be leveraged instead of producing something entirely new. There's quite a bit of investment in those projects... Does that make more sense what I was trying to say?

The reason for not using LLVM bitcode or ASM.js is already covered in detail here https://github.com/WebAssembly/design/blob/master/FAQ.md

I am unsure how JVM or CLR are relevant. WebAssembly is not a virtual machine byte code (and neither is LLVM, despite the name). As the name "WebAssembly" suggests, it is like an assembly language level target for "the web" (more precisely, for JavaScript interpreters found in web browsers).

It is true that there is a lot of unfortunate duplication of effort and fracturing of technology happening here, due to historical legacy issues with web browsers. JVM and CLR are indeed highly mature and presumably secure VMs today. If we were to wave a magic wand and rewrite the history of the web browsers, perhaps it would be much better if JavaScript never existed and browsers used an off-the-shelf, standardized VM like JVM or CLR and we wrote web apps in C# or Java (or, at our discretion, F#, etc). This wouldn't solve the problem that WebAssembly is solving (i.e compiling native code, eg C++, for execution in the browser), but then maybe we wouldn't have needed that today if everyone (native and web) had standardized on a single VM target. But that's just not how things turned out, browsers created their own parallel technology stack from scratch so things like WebAssembly need to be created from scratch to work within the constraints that we are stuck with.

Re: A first look at WebAssembly performance

#70

Post by hajile »

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?

Post reply on HN