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

51–59 of 59 posts

Re: Analyzing the Performance of WebAssembly vs. Native Code

#51

Post by fainpul »

degamad wrote: post #50
gjm11 wrote: post #27

Earlier quoted context omitted.

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

What would 300% faster mean? If the original process took 30 minutes to process 10 items, how long would the 300% faster method take?

300% faster = 400% original speed = 4 times as fast = 1/4 the time

Re: Analyzing the Performance of WebAssembly vs. Native Code

#52

Post by bloppe »

qingcharles wrote: post #49
bloppe wrote: post #28

Earlier quoted context omitted.

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.

How does .Net stack up?

I'm not too sure, but the main reason MS developed it was because they just wanted Java without licensing it from Oracle, so I imagine they made a lot of similar design decisions.

Anyway, it's great if you compile it to Wasm.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#53

Post by bloppe »

hashmash wrote: post #42
bloppe wrote: post #28

Earlier quoted context omitted.

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.

The Java runtime isn't any more inherently insecure than the JavaScript runtime, and JavaScript seems to work just fine for the web. The key reason why applet security failed was because it gave you the entire JDK by default, and so every method in the JDK needed to have explicit security checking code in place to restrict access. The model was backwards -- full control by default with selective disabling meant that…

Just look up "Java applet sandbox escape". There were tons of ways to do it. Here are some [0]. Then there's the coarse-grained permissions that were essentially useless to begin with.

[0]: https://phrack.org/issues/70/7

Re: Analyzing the Performance of WebAssembly vs. Native Code

#54

Post by hashmash »

bloppe wrote: post #53
hashmash wrote: post #42

Earlier quoted context omitted.

The Java runtime isn't any more inherently insecure than the JavaScript runtime, and JavaScript seems to work just fine for the web. The key reason why applet security failed was because it gave you the entire JDK by default, and so every method in the JDK needed to have explicit security checking code in place to restrict access. The model was backwards -- full control by default with selective disabling meant that…

Just look up "Java applet sandbox escape". There were tons of ways to do it. Here are some [0]. Then there's the coarse-grained permissions that were essentially useless to begin with. [0]: https://phrack.org/issues/70/7

Yes, I'm familiar with these. Many of the earliest problems were to due bugs in the verifier, and there were several different vendors with their own set of bugs. The bulk of these problems were identified and resolved over 25 years ago.

Most of the later problems are due to the fact that the API attack surface was too large, because of the backwards SecurityManager design. And because it existed, it seems there was little incentive to do something better.

Once the instrumentation API was introduced (Java 5), it made it easier to write agents which could limit access to APIs using an "allow" approach rather than the awful rules imposed by the SecurityManager. Java 9 introduced modules, further hardening the boundaries between trusted and untrusted code. It was at this point the SecurityManager should have been officially deprecated, instead of waiting four more years.

Going back to the earlier comment, the problem isn't due to the runtime being somehow inherently insecure, but instead due to the defective design of the SecurityManager. It hasn't been necessary for providing security for many years.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#55

Post by degamad »

fainpul wrote: post #51
degamad wrote: post #50

Earlier quoted context omitted.

What would 300% faster mean? If the original process took 30 minutes to process 10 items, how long would the 300% faster method take?

300% faster = 400% original speed = 4 times as fast = 1/4 the time

Of course, my mind glossed over the point that the factor is being applied to the speed, so 300% faster than 20 items per hour is 80 items per hour. That makes sense. It's also analogous to "300% more than 20 is 80".

But then it's hard to make sense of the idea that 300% slower is 5 items per hour (if I'm understanding correctly), since it works differently from "75% less than 20 is 5".

Re: Analyzing the Performance of WebAssembly vs. Native Code

#56

Post by fainpul »

degamad wrote: post #55
fainpul wrote: post #51

Earlier quoted context omitted.

300% faster = 400% original speed = 4 times as fast = 1/4 the time

Of course, my mind glossed over the point that the factor is being applied to the speed, so 300% faster than 20 items per hour is 80 items per hour. That makes sense. It's also analogous to "300% more than 20 is 80". But then it's hard to make sense of the idea that 300% slower is 5 items per hour (if I'm understanding correctly), since it works differently from "75% less than 20 is 5".

Yeah, "more slower" is indeed a weird way to phrase something. People should just refer to the absolute values, not to the differences. E.g. "1.4 times as fast as …" or "1/2 as heavy as …".

If I read "300% slower", I like to think about time, not speed.

300% more time = 400% original time = 4 times as long = 1/4 the speed

Re: Analyzing the Performance of WebAssembly vs. Native Code

#58

Post by degamad »

fainpul wrote: post #56
degamad wrote: post #55

Earlier quoted context omitted.

Of course, my mind glossed over the point that the factor is being applied to the speed, so 300% faster than 20 items per hour is 80 items per hour. That makes sense. It's also analogous to "300% more than 20 is 80". But then it's hard to make sense of the idea that 300% slower is 5 items per hour (if I'm understanding correctly), since it works differently from "75% less than 20 is 5".

Yeah, "more slower" is indeed a weird way to phrase something. People should just refer to the absolute values, not to the differences. E.g. "1.4 times as fast as …" or "1/2 as heavy as …". If I read "300% slower", I like to think about time, not speed. 300% more time = 400% original time = 4 times as long = 1/4 the speed

And that's where the confusion comes from: according to this, 300% faster refers to 300% more speed, whereas 300% slower refers to 300% more time.

Re: Analyzing the Performance of WebAssembly vs. Native Code

#59

Post by jedisct1 »

Really depends on the application. WebAssembly can't use SIMD intrinsics and CPU-specific instructions besides simd128 and what the compiler can do.

At least for cryptography, WebAssembly can be very slow and can hardly provide any guarantee against side channels.

Post reply on HN