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

181–190 of 212 posts

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

#181

Post by tracker1 »

hinkley wrote: post #162
flohofwoe wrote: post #46

FWIW: in my 8-bit emulators I'm closer to the 10% performance difference for code compiled in clang with -O3 (the native version uses latest Xcode's clang, the WASM the latest LLVM WASM backend via emscripten): https://floooh.github.io/tiny8bit/cpc-ui.html The time in the top-right is the time spent per frame in the emulator, in the WASM version that's somewhere around 2.5 to 2.8ms on my laptop. The native version is…

But 10% is something I can easily sell to my boss. I only need one or two compensating qualities for that argument to succeed. If I'm getting work done faster, prioritizing a couple more perf stories is a reasonable tax to pay.

It depends on what you are trying to do... you can only spend so much CPU time on a blinking cursor waiting for a user to click/type something.

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

#182

Post by tracker1 »

nerdponx wrote: post #50
flohofwoe wrote: post #24

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). And Windows is closing the "gap" really fast too. Try distributing a native installer without the browser or SmartScreen bringing up a scare-dialog-box. Until OS vendors are willing to provide a safe sandbox to run untrusted code in, and untangled from a non-t…

I recently switched to desktop GNU/Linux full time outside of work, and I have to say it's really damn good now. Mind you, I'm using a Lenovo laptop, so it's among the best supported hardware you can buy for the purpose. But the fact that there aren't more boutique computer makers selling GNU/Linux systems installed by default is an interesting statement on the industry. I'm sure ultimately it comes down to the avail…

Beyond that, with flatpak and wasm application sandboxes, it will only get better. Wasm, provided some UI primitives and OS-like primitives get baked in, will give a common runtime for UI apps everywhere without a full browser. WASM+Canvas or WASM+WebGL can/will go a LONG way.

I would say, that enough OS primitives should be present so that as an example SQLite3 can compile and run, and you can get a compatible file out the other end.

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

#183

Post by tracker1 »

Razengan wrote: post #65
flohofwoe wrote: post #24

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). And Windows is closing the "gap" really fast too. Try distributing a native installer without the browser or SmartScreen bringing up a scare-dialog-box. Until OS vendors are willing to provide a safe sandbox to run untrusted code in, and untangled from a non-t…

> Can you distribute a native application on macOS without Apple's blessing? No, you can't Yes, you can. You have always been able to. > (not when Catalina will be out anyway). Yes, you will be able to. I just downloaded a music tracker/MOD player from the Mesozoic (well, not quite) and it runs fine on Catalina Developer Preview 4. I can understand the confusion – I had the same concerns while watching this year's WW…

Running an unsigned app is a bit of a pain... though, imho probably worth it for the modest improvement in security.

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

#184

Post by tracker1 »

microtonal wrote: post #42
flohofwoe wrote: post #24

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). And Windows is closing the "gap" really fast too. Try distributing a native installer without the browser or SmartScreen bringing up a scare-dialog-box. Until OS vendors are willing to provide a safe sandbox to run untrusted code in, and untangled from a non-t…

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…

> We have to run untrusted and unchecked code of vendors who run code to track your movements around the web and in their applications? (Even worse)

I don't think that is the case. Simply because a WASM application will have to request the permissions it needs up front (assuming a sane runtime) and you don't have to give anything run in background permissions... also, it won't have access to other apps, so it can't really track you.

The bigger issue with Desktop linux is very few people run it, and targeting a specific subset for linux as separate from other platforms is difficult and costly, to say the least.

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

#185

Post by tracker1 »

bartq wrote: post #91
PaulHoule wrote: post #34

Earlier quoted context omitted.

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.

WASM + Canvas or WASM + OpenGL should give a significant part of that... but what made flash really special was the tooling around it. I wouldn't be surprised to see Adobe make some strides there, but the output may be less than optimal.

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

#186

Post by tracker1 »

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?

I think it's a mixed bag... a lot of developers think they know JavaScript or understand web applications. I've found that about 90% are not very good with it in practice. Often with job titles as Mid or Sr developers.

Actually understanding more about JS and the browser, and actual application development, and how it fits are good places to start. I find that the browser model actually fits a redux-like master state machine better than MV* that a lot of experienced developers, but inexperienced web app developers tend to focus on.

It just depends. I think there's room for most players, and IU do think WASM offers a LOT or will as runtimes and standard libraries shake out. I'm looking forward to seeing things develop more... IMHO there should be a focus to standardize interfaces for Canvas, WebGL, Audio and FS first. When you can run an application against canvas 2d or webgl with audio and sqlite, I think that's a large way there. Better input support (controllers as well as kb/mouse) is also pretty high. I know people are working on these things.

Getting something that runs almost everywhere will be very nice and although there's some overlap with the intent of the JVM, WASM has more primitive options (for the good) and can support a greater range of sources to a single target set of interfaces.

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

#187

Post by tracker1 »

usefulcat wrote: post #75
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…

> Slower at an average of 50% looks acceptable to me for many applications. Sure, but what about shorter battery life? Granted it would probably not be 50% shorter battery life since there are many other things (screen, disk, networking) that also consumer power, but still..

Native device platforms could do a system optimized AOT compile of WASM to Native as part of install. The distribution can be the same per platform, that doesn't stop a given platform from further optimization.

Also, the single biggest battery use for most people is the screen, the CPU time is minimal by comparison and that 50% is only for the narrow CPU time the app isn't just waiting for input, and for many apps, that's most of the time (idle).

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

#188

Post by tracker1 »

em-bee wrote: post #98
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 win…

Exactly this... I use all three as well, and tend to favor apps that run everywhere. Even if that means browser/electron apps. It's just less hassle for me. My single biggest issue is windows-isms for bash on windows.

In the end, as long as it works, I'm very happy. Also, it doesn't preclude a given platform from AOT optimization/compile for WASM code to platform native code. I think getting common runtime interfaces is currently the paramount point... being able to use sqlite, and SDL/OpenGL adapters to canvas or webgl are also big. Not to mention audio, and various input devices (gamepads etc).

There is a lot of existing code that could be readily ported/shimmed out if we can get some common interfaces working.

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

#189

Post by ScottFree »

AnIdiotOnTheNet wrote: post #171
typon wrote: post #168

Earlier quoted context omitted.

Yes, a million times better.

And this is why we can't have nice things.

What's your definition of "nice?" I've never heard anybody describe a java applet that way.

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

#190

Post by emeryberger »

leshow wrote: post #152

I didn't watch the video, does it say how much of the perf gap is due to the unix API's they tried to replicate and how much is due to wasm actually being 'slower'? 50% the speed of native is really not bad, it's not like wasm is done being worked on. That's a very promising start.

(I'm one of the paper authors.) The paper points out that the overhead of Browsix-WASM is under 1% across all benchmarks.
Post reply on HN