Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Analyzing the Performance of WebAssembly vs. Native Code

ar5iv.labs.arxiv.org

Post reply on HN
Print view View original

21–30 of 59 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#21

Post by pron »

andyferris wrote: post #9
icsa wrote: post #3

45% slower to run everywhere from a single binary... I'll take that deal any day!

45% slower to run everywhere from a single binary... with less security holes, without undefined behavior, and trivial to completely sandbox. Its definitely a good deal!

> without undefined behavior

Undefined behaviour is defined with respect to the source language, not the execution engine. It means that the language specification does not assign meaning to certain source programs. Machine code (generally) doesn't have undefined behaviour, while a C program could, regardless of what it runs on.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#24

Post by wmf »

b_e_n_t_o_n wrote: post #15

45% slower seems pretty decent considering they use a wasm kernel they developed to mimic the unix kernel so they can run non-modified unix programs inside the browser. It's actually pretty impressive that they did this, and even more impressive that it works and like another commentator said, is not even an order of magnitude slower. I'm more interested in 1) usages of wasm in the browser that don't involve running…

wasm outside the browser for compile-once-run-anywhere usecases with sandboxing / security guarantees

Please just use Docker in a microVM or whatever. It's 0% slower and 100% more mature.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#25

Post by tharakam »

PantaloonFlames wrote: post #10

45% slower means..? Suppose native code takes 2 units of time to execute. “45% slower” is??? Would it be 45% _more time?_ What would “45% _faster_” mean?

I guess it is clearer if expressed like "Native application took only x% of WASM equivalent".

Re: Analyzing the Performance of WebAssembly vs. Native Code

#26

Post by rowanG077 »

wmf wrote: post #24
b_e_n_t_o_n wrote: post #15

45% slower seems pretty decent considering they use a wasm kernel they developed to mimic the unix kernel so they can run non-modified unix programs inside the browser. It's actually pretty impressive that they did this, and even more impressive that it works and like another commentator said, is not even an order of magnitude slower. I'm more interested in 1) usages of wasm in the browser that don't involve running…

wasm outside the browser for compile-once-run-anywhere usecases with sandboxing / security guarantees Please just use Docker in a microVM or whatever. It's 0% slower and 100% more mature.

Setting up docker and a microVM is orders and orders of magnitude harder and less ergonomic then using your browser. These are not at all interchangeable.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#27

Post by gjm11 »

PantaloonFlames wrote: post #10

45% slower means..? Suppose native code takes 2 units of time to execute. “45% slower” is??? Would it be 45% _more time?_ What would “45% _faster_” mean?

What looks like the relevant table has a summary line saying "geometric mean: 1.45x" so I think that in this case "45% slower" means "times are 1.45x as long".

(I think I would generally use "x% slower" to mean "slower by a factor of 1+x/100", and "x% faster" to mean "faster by a factor of 1+x/100", so "x% slower" and "x% faster" are not inverses, you can perfectly well be 300% faster or 300% slower, etc. I less confidently think that this is how most people use such language.)

Re: Analyzing the Performance of WebAssembly vs. Native Code

#28

Post by bloppe »

gishh wrote: post #11
icsa wrote: post #3

45% slower to run everywhere from a single binary... I'll take that deal any day!

That which is old is new again. The wheel keeps turning… “Wait we can use Java to run anywhere? It’s slow but that’s ok! Let’s ride!”

There's a reason Java applets got deprecated in every browser. The runtime was inherently insecure. It just doesn't work for the web.

Also, targeting the JVM forces you to accept garbage collection, class-based OO and lots of pointer chasing. It's not a good target for most languages.

Java's pretty good, but wasm is actually a game changer.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#29

Post by bjconlan »

astafrig wrote: post #7
turbolent wrote: post #2

... in browsers. Which at best JIT compile. There are several WASM runtimes that AOT compile and have significantly better performance (e.g. ~5-10% slower). The title is highly misleading.

It’s not misleading to measure the performance of Web Assembly in a web browser .

Yeah, but it's specifically testing things that implement against a posix API (because generally that's what "native" apis do (omiting libc and other os specific foundation libraries that are pulled in at runtime or otherwise) I would suspect that if the applications that linked against some wasi like runtime it might be a better metric (native wasi as a lib/vs a was runtime that also links) mind you that still wouldn't help the browser runtime... But would be a better metric for wasm (to native) performance comaparison.

But as already mentioned we have gone through this all before. Maybe we'll see wasm bytecodes pushed through silicon like we did the Jvm... Although perhaps this time it might stick or move up into server hardware (which might have happened, but I only recall embedded devices supporting hardware level Jvm bytecodes).

In short the web browser bit is omitted from the title.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#30

Post by gishh »

bloppe wrote: post #28
gishh wrote: post #11

Earlier quoted context omitted.

That which is old is new again. The wheel keeps turning… “Wait we can use Java to run anywhere? It’s slow but that’s ok! Let’s ride!”

There's a reason Java applets got deprecated in every browser. The runtime was inherently insecure. It just doesn't work for the web. Also, targeting the JVM forces you to accept garbage collection, class-based OO and lots of pointer chasing. It's not a good target for most languages. Java's pretty good, but wasm is actually a game changer.

I am a huge, huge fan of wasm. The first time I was able to compile a qt app to Linux, windows, Mac, and wasm targets, I was so tickled pick it was embarrassing. Felt like I was truly standing on the shoulders of giants and really appreciated the entirety of the whole “stack” if you will.

Running code in a browser isn’t novel. It’s very circular. I actually met someone the other day that thought JavaScript was a subset of Java. Same person was also fluent in php.

Wasm is really neat, I really love it. My cynical take on it is that, at the end of the day, it’ll just somehow help ad revenue to find another margin.

Post reply on HN