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

How WebAssembly Changes Software Distribution

desiatov.com

Post reply on HN
Print view View original

51–60 of 69 posts

Re: How WebAssembly Changes Software Distribution

#51

Post by egypturnash »

"It would be fair to say that these attempts failed to establish wide adoption"

Wait what Flash spawned an entire generation of game developers and animators, it was ubiquitous. It had many problems and I am generally not sad to see it gone but saying it "failed to establish wide adoption" is only a valid thing if this person has a completely different definition of "wide adoption" than I do.

Flash was largely constrained to games but there were definitely a lot of people using it as the backbone, or an important part, of their interactive web apps, too. Adobe tried to turn it into a desktop runtime but there weren't too many people biting. I guess "actually runs tools people use on a daily basis" is the "wide adoption" they intend?

Does "Youtube was built around a Flash video playback component" count as "wide adoption"? Does "just about every Facebook game was built in Flash, including the vastly profitable ones that invented and perfected the concept of free-to-play-with-IAP" count? A hell of a lot of people exchanged a hell of a lot of money around stuff made with Flash.

You can't compile C and other languages to it (though Adobe was working on it: https://web.archive.org/web/20080827114529/http://www.onflex...) , and maybe that's the threshold they want for "wide adoption" given that there's a whole segment later on in this blog about how you can compile C to WASM?

(Judging by the photo at the top of this blog, it's eminently possible that Max Desaitov is young enough that their only encounter with Flash was "those games I was utterly obsessed with in single-digit ages and never realized were in Flash"... god I'm old)

Perhaps WASM finally has all the right infrastructure to finally become the One True Compiler Target, and all apps will disappear into The Cloud forever. Perhaps. Or perhaps in about twenty-five years, Max Desaitov will be writing a comment expressing disbelief at some doe-eyed child adding WASM to their list of previous attempts to Change Software Distribution Forever and then going on to rave excitedly about why the next attempt to do this will surely be The One. Or perhaps Max will be too busy scrambling around in the burnt-out remnants of a capitalist empire that finally collapsed, right now that feels like a worrisomely possible future, who knows.

Re: How WebAssembly Changes Software Distribution

#52

Post by maxgraey »

estrela wrote: post #46

I have some experience with Blazor WebAssembly, and in my opinion, the technology is promising but imature. Whenever a complex page is rendered (a table with hundreds of entries, ...), you can definitely notice how slow and memory consuming it is.

Probably Blazor is immature, but not WebAssembly? Blazor btw run in interpreted mode for CIL modules. Full AOT compilation was planned for .NET 5 but canceled. But you could check rust's frameworks like Yew. That's real world demo: https://github.com/jetli/rust-yew-realworld-example-app

Re: How WebAssembly Changes Software Distribution

#53

Post by qppo »

johncolanduoni wrote: post #48
qppo wrote: post #24

Earlier quoted context omitted.

I dont think it would help at all for compiled languages actually. The reason that they distribute source instead of binaries is mostly due to feature flags and conditional compilation. Seems a bit off track too. WASM is a very lossy compile target and that's not acceptable for most compiles languages which need explicitness and assumptions about the target machine for their optimizations (ones written by the program…

WASM’s memory access sandboxing is actually pretty cheap in most implementations; all the major browser engines now use reserved virtual memory with a segfault handler on most systems instead of range checks.

This just cements my belief that the abstraction presented by system allocators is insufficient for modern applications. This shouldn't be done (or necessary) in userspace.

Re: How WebAssembly Changes Software Distribution

#54

Post by qppo »

joshum97 wrote: post #35
qppo wrote: post #24

Earlier quoted context omitted.

I dont think it would help at all for compiled languages actually. The reason that they distribute source instead of binaries is mostly due to feature flags and conditional compilation. Seems a bit off track too. WASM is a very lossy compile target and that's not acceptable for most compiles languages which need explicitness and assumptions about the target machine for their optimizations (ones written by the program…

Good point about conditional compilation. It’s a trade off I’ll leave for language implementors to make. I tend to think that easily preventing a malicious package from sending your file system contents to some server is usually worth 10-20% perf loss, and that might even be made up by Wasm SIMD and other proposals.

Capability based security models should solve that without perf loss, it's just unfortunate they aren't widespread or useful enough yet.

And not to discount your threat model which is a bit hyperbolic, but in applications where you've already making the decision to use a difficult-to-sandbox compiled language, you're not going to have the same justification.

WASM makes a lot of sense for the web where we have mounds of untrusted code, much of which needs to be fast, and is trivial to inadvertently be executed by an unsuspecting user. That's not necessarily true for native applications. The real travesty is the divide between web and native has been so blurred that it's hard to see where it is anymore.

Re: How WebAssembly Changes Software Distribution

#55

Post by rkeene2 »

dmitriid wrote: post #43
rkeene2 wrote: post #42

Earlier quoted context omitted.

The LLVM IR isn't portable. e.g., you can't take the LLVM IR for one CPU or OS and use it on another CPU or OS.

Ah, didn't realize it wasn't portable.

It makes sense if you think about it -- the front-end that used LLVM to create this IR consumed a whole lot of platform specific information, like the layout of structs, system call numbers, library names, and function names, etc and distilled it to something that knows the results of those things but no longer knows how they were derived, so it couldn't be applied as-is to some other platform.

This is why WebAssembly needs a runtime framework for making things outside WebAssembly accessible to WebAssembly code -- it has to build an abstraction around all kinds of different systems.

It's even worse, though, for LLVM IR, since it targets a specific type of CPU in various ways, where WebAssembly is a single ISA.

Re: How WebAssembly Changes Software Distribution

#56

Post by swalsh »

Rochus wrote: post #12
NationalPark wrote: post #6

Earlier quoted context omitted.

I think you have the performance differences backwards, wasm is usually quite a bit faster than comparable javascript. While it's true that right now there are additional overhead costs for browser APIs, that's changing, but it's also misunderstanding the value proposition of wasm. You can write an entire front end web application if you want, but it really shines for library code and computationally expensive code.…

> wasm is usually quite a bit faster than comparable javascript Even if true, it doesn't help much if you have to marshall through JS for nearly every call. > You can write an entire front end web application if you want One of the core benefit propositions was the possibility to write browser applications in any language, not just JS.

> Even if true, it doesn't help much if you have to marshall through JS for nearly every call.

If you're doing a lot of cheap calls, it's probably not the optimal way to get a performance boost. I think Web Assembly shines at taking an expensive function, and doing it faster. For example, let's say I wanted to multiple a few large matricies of values. In Javascript this would be VERY slow. In Web Assembly it would be a bit faster, but then Web Assembly plus Web GPU allows me to do it REALLY fast. Yes, I'd then have to marshal the end result back to javascript but that's still cheaper then trying to do all that math natively in Javascript.

Re: How WebAssembly Changes Software Distribution

#57

Post by JoshTriplett »

CyberDildonics wrote: post #45
Rochus wrote: post #36

Earlier quoted context omitted.

Thanks for the info. My laptop has about the same age. Maybe you have the much faster graphics chip than my HP EliteBook.

Drawing a few boxes with webgl has nothing to do with a graphics card. This is about webasm which is single core performance.

And yet the graphics are actually the performance bottleneck.

I tried that on a 4k monitor, and it ran quite slowly. I then made the window smaller, and it ran much faster. It's bottlenecked on the graphics, not on the physics engine.

Re: How WebAssembly Changes Software Distribution

#58

Post by CyberDildonics »

JoshTriplett wrote: post #57
CyberDildonics wrote: post #45

Earlier quoted context omitted.

Drawing a few boxes with webgl has nothing to do with a graphics card. This is about webasm which is single core performance.

And yet the graphics are actually the performance bottleneck. I tried that on a 4k monitor, and it ran quite slowly. I then made the window smaller, and it ran much faster. It's bottlenecked on the graphics, not on the physics engine.

I think that says a lot more about your combination of software and hardware than webasm.

If someone says "webasm is slow, this demo took 45 seconds to run" and you say "it ran slow for me when I made the window so big that between my browser's webgl implementation, my gpu drivers and my graphics card, a hundred cubes make everything run at 1/10th the speed" what point is that making?

Post reply on HN