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

Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

usenix.org

Post reply on HN
Print view View original

91–100 of 212 posts

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#91

Post by bartq »

PaulHoule wrote: post #34
gioele wrote: post #26

Earlier quoted context omitted.

We already had "instant (no install) apps that are inherently sandboxed": Java and its net-top boxes. Why didn't it work?

Many things. I was involved with Java applets when Java was in beta and one of the most annoying things was that JDK 1.0 did not come with serialization. I would build applets that displayed content generated on the server and serialization-deserialization code could be 2/3 of the program. Most people had a slow net back then, so the download performance was a big deal. JDK 1.1 put serialization in right away, but Ne…

I'd really like to see Flash reborn on WASM. WASM is a standard, so there will be no problems known to software produced and distributed by a private business (Macromedia/Adobe), problems like closed format, resources access control etc.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#92

Post by CalChris »

not_a_cop75 wrote: post #48
cjfd wrote: post #41

Earlier quoted context omitted.

People might start baking chips that can natively run web assembly at some point. If that happens we have found a very expensive path from running native binaries to running native binaries for the purpose of making this independent of the platform.

Lol. Well, I mean nothing is outside of the realm of possibility, but remember those native Java chips! Some thought those were going to be a big win. And then you had companies like Transmeta trying to do the exact opposite - interpretively optimize all the things....or something like that.

Transmeta JIT'd x86 into VLIW.

That was right before the Power Wall became an obstacle and CPUs were already burning up. Transmeta in a sense invented low power computing but then Intel said thank you very much; we'll take it from here. It wasn't that they didn't deliver. It's just that they were competing against Intel in the x86 space. A lot of the Transmeta team moved to nVidia and work on Denver but that's different and they got an architecture license from ARM to do that.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#93

Post by CalChris »

Ididntdothis wrote: post #78
cjfd wrote: post #41

Earlier quoted context omitted.

People might start baking chips that can natively run web assembly at some point. If that happens we have found a very expensive path from running native binaries to running native binaries for the purpose of making this independent of the platform.

A long time ago they were talking about Java chips. That didn’t materialize and as far as I know there are no chips that run JavaScript natively so I wouldn’t hold my breath for WebAssembly chips.

The Java chips were for, well, they were for Java. If ARM had designed Jazelle to be more general, it would have been useful for Javascript and Python and .... But they designed it for Java bytecode. The licensing was too expensive and so it didn't catch on and Jazelle got dropped from ARMv8.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#94

Post by FpUser »

bigato wrote: post #76
microtonal wrote: post #42

Earlier quoted context omitted.

But it's the other way around. Can you distribute a native application on macOS without Apple's blessing? No, you can't (not when Catalina will be out anyway). Yes you can: https://forums.macrumors.com/threads/unsigned-apps-catalyst-... WASM is the next best thing to an open, yet secure, platform. So, instead of walled gardens with signed and checked applications (bad). We have to run untrusted and unchecked code of…

> So, instead of walled gardens with signed and checked applications (bad). We have to run untrusted and unchecked code and sandboxed. yes, this is way forward.

"yes, this is way forward." - I don't think so

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#95

Post by gok »

If anything this paper is unfair to the native compiler; they compare V8 and SpiderMonkey from April 2019 to a clang release from March 2017, and they turn off autovectorization. That being said, most of the slowdowns they identify seem to be deficiencies in the WASM engines rather than fundamental problems with WASM itself.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#96

Post by kristiandupont »

AnIdiotOnTheNet wrote: post #71
kowdermeister wrote: post #20

Earlier quoted context omitted.

> Why do we - developers fall into this trap? Regardless of is this a trap or not, it's obvious to me that developers want simplicity and consistency. WA provides both so don't wonder why it's taking off. > So instead of Linux/Windows/OSX we will have Firefox/Safari/Chrome/Whatever all with their own implementation gotchas I let the compilers worry about this :)

Yes, declaring the hard parts to be someone else's problem always works out in the end, doesn't it? Hopefully in 20 years, when people are talking about MetaWebAssembly to abstract away the platforms that run on WASM, you'll have a different perspective on what you've said here.

Oh come on. If you are doing any kind of development, you too, are relying on abstractions and someone elses machinery. That doesn't make you lazy or amoral or something.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#97

Post by FpUser »

kristiandupont wrote: post #64
FpUser wrote: post #40

Earlier quoted context omitted.

There is no free lunch in this universe. For big applications like CAD there will be nothing "instant" for in case of deployment as web apps. Downloading native packed archive and running install may actually be faster.

Sure, there are exceptions. Cinemas also still receive movies as physical harddrives for a number of reasons, but for most people and situations, streaming is fine.

I am not sure about "most people" but I use fair number of applications (not including software development tools here as they do not pass"most people" criteria ) and none of those are streamed. Every time I try anything web based, online Tetris excepted ;) it sucks one or the other way

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#98

Post by em-bee »

microtonal wrote: post #32

Slower at an average of 50% looks acceptable to me for many applications. However, for me personally I wonder: what's the point? I would go from Linux -> glibc -> native application to Linux -> glibc -> Web Browser -> WebAssembly application. Yet another layer of abstraction. Sure, WebAssembly can be run directly on any platform. But precompiling an application is not a problem (my Linux distribution provides binary…

sure, you can compile an application, but if you want to target everyone, you have to do it on at least 3 architectures (linux, mac, windows)

and as a user, i am either lucky if my architecture is supported, or i am scrambling to find an alternative.

in my case i actually have all three. so when i see a new application i want to try, i check which one is best supported and then pick that.

several apps run only on windows. some on mac and windows, some others on mac and linux. occasionally there is a mac or linux only application. and once in a while an application binary is available on all three.

this is not even an issue of portability. even if the application is easily portable, i still depend on the developers choice of which OS they support. and i can't blame them. unless i am going to make money off the application i am not going to bother with supporting windows or macos. and most others will continue to ignore linux because the smaller market is still not always worth the effort.

with webassembly we finally get a unified binary architecture.

if an application run on webassembly, then the OS no longer matters. as someone that prefers to use linux. webassembly is like the holy grail. because if it manages to take hold, then hopefully the days of needing windows or a mac will be gone.

that's the point.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#99

Post by FpUser »

ScottFree wrote: post #72
FpUser wrote: post #49

Earlier quoted context omitted.

"...Last but not least, web developers are the biggest pool to hire from..." For boiler plate business web apps sure. And while those are probably being prevalent the world does not stop there.

Companies are running webapps on embedded devices now, but I don't buy the ease of hiring excuse. Web devs demand higher salaries than embedded developers and they have more leverage in terms of where they can work (ie: they're flaky as pie crust). Embedded developers are also more likely to pass the hazing ritual known as the programming interview. Where's the upside to hiring web developers in that context?

"Companies are running webapps on embedded devices now" - sure my router and some of my own private hardware have web interfaces. It is however just a tiny bit of their functionality. The rest leaves happily as native code.

Re: Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code

#100

Post by snek »

jakobegger wrote: post #25

Can someone explain a concrete use case for web assembly? Are there projects out there using web assembly in production? What kind of application needs more performance than Javascript can offer, but doesn't need full native performance?

> Are there projects out there using web assembly in production?

pspdfkit, unity, google earth, and figma spring to mind. Obviously more stuff is using it, but it isn't like there's a big index of sites using wasm.

> What kind of application needs more performance than Javascript can offer, but doesn't need full native performance?

Wasm and JS can achieve equal performance in modern browser engines (and note that in engines like v8, there are operations that can be reduced such that they compete with output from gcc and clang). The thing that wasm is designed to do is make that performance predictable. Optimizing JS requires a lot of guesswork which can end up incorrect, while wasm doesn't require any guesswork because it is strongly typed and uses a regular bytecode. Right now what is holding wasm back is coming up with all the best ways to reduce it to the machine code of the specific platform, and ways to reduce the performance hits of security checks wasm has. For example, v8 recently sped up wasm memory access by ~30% by getting rid of bounds checks and using mmap + sigsegv to detect out of bounds access.

Post reply on HN