How WebAssembly Changes Software Distribution • Hacker News Board

Re: How WebAssembly Changes Software Distribution

#41

Post by wtetzner » Wed, Sep 09, 2020, 2:55 PM UTC

wffurr wrote: post #9

Rochus wrote: post #2

Despite the author's obvious enthusiasm: WASM has a long way to go before it is really useful. From my humble perspective there was not much progress since the 1.0 release. As long as every access to the host (especially the GUI) is tunneled via JavaScript, one shouldn't be surprised about the low performance and the enormous memory consumption. See what happens behind the scenes when you set a pixel in the SDL API w…

It does feel like WebAssembly development has stalled after the initial release. There are proposals for reference types, garbage collection, and host bindings that would greatly expand a WebAssembly binary's capabilities, but they haven't been implemented in any browser, much less standardized yet. WebAssembly proposals tracker: https://github.com/WebAssembly/proposals WebAssembly reference types ( https://github.co…

I'm still waiting for tail call optimization. By not having support for it, a bunch of languages are either forced to not bother with WASM, or have to do something like trampolines and give up performance.

Re: How WebAssembly Changes Software Distribution

#42

Post by rkeene2 » Wed, Sep 09, 2020, 2:56 PM UTC

dmitriid wrote: post #27

joshum97 wrote: post #23

I think Wasm outside the browser could benefit package managers. As far as I know, Rust and some other compiled languages distribute their crates/packages in source code form, which then have to be compiled before use. If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Plus, you’d get safety guarantees to make sure a package isn’t doing anything it hasn’t…

> If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Why though? For compiled languages it would make significantly more sense to distribute them in LLVM intermediate representation than WASM.

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.

Re: How WebAssembly Changes Software Distribution

#43

Post by dmitriid » Wed, Sep 09, 2020, 2:57 PM UTC

rkeene2 wrote: post #42

dmitriid wrote: post #27

Earlier quoted context omitted.

> If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Why though? For compiled languages it would make significantly more sense to distribute them in LLVM intermediate representation than WASM.

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.

Re: How WebAssembly Changes Software Distribution

#44

Post by dmitriid » Wed, Sep 09, 2020, 2:57 PM UTC

joshum97 wrote: post #32

dmitriid wrote: post #27

Earlier quoted context omitted.

> If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Why though? For compiled languages it would make significantly more sense to distribute them in LLVM intermediate representation than WASM.

I would agree with you, except that LLVM IR isn’t platform independent. For all of Wasm’s warts it’s the best supported low level cross platform IR we have.

Well, I'll be! This really is a sad development IMO.

Re: How WebAssembly Changes Software Distribution

#45

Post by CyberDildonics » Wed, Sep 09, 2020, 2:59 PM UTC

Rochus wrote: post #36

CyberDildonics wrote: post #30

Earlier quoted context omitted.

I tried the same thing and it took 4 seconds on my 8 year old computer.

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.

Re: How WebAssembly Changes Software Distribution

#46

Post by estrela » Wed, Sep 09, 2020, 3:01 PM UTC

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.

Re: How WebAssembly Changes Software Distribution

#47

Post by Rochus » Wed, Sep 09, 2020, 3:04 PM UTC

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.

From https://en.wikipedia.org/wiki/WebGL:

"WebGL is fully integrated with other web standards, allowing GPU-accelerated usage of physics and image processing and effects as part of the web page canvas"

So I would guess that when your graphics chip is faster than mine you get a higher performance.

Re: How WebAssembly Changes Software Distribution

#48

Post by johncolanduoni » Wed, Sep 09, 2020, 3:05 PM UTC

qppo wrote: post #24

joshum97 wrote: post #23

I think Wasm outside the browser could benefit package managers. As far as I know, Rust and some other compiled languages distribute their crates/packages in source code form, which then have to be compiled before use. If packages were distributed in Wasm (plus headers/type declarations), you could JIT or quickly AOT compile them. Plus, you’d get safety guarantees to make sure a package isn’t doing anything it hasn’t…

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.

Re: How WebAssembly Changes Software Distribution

#49

Post by pmoriarty » Wed, Sep 09, 2020, 3:07 PM UTC

I am interested in how WASM will affect in-browser ad blockers like uBlock Origin that work on a finer grain than merely blocking entire domains. Will they still be effective?

Also, how will WASM affect browser extensions that change the look and feel of websites (like Stylish/Stylus), or the means of interacting with them (like Vimperator)?

These questions all boil down to how much control is the end-user going to have with WASM compared to what they had with the pre-WASM web?

Re: How WebAssembly Changes Software Distribution

#50

Post by CyberDildonics » Wed, Sep 09, 2020, 3:10 PM UTC

Rochus wrote: post #47

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.

From https://en.wikipedia.org/wiki/WebGL : "WebGL is fully integrated with other web standards, allowing GPU-accelerated usage of physics and image processing and effects as part of the web page canvas" So I would guess that when your graphics chip is faster than mine you get a higher performance.

These two things have nothing to do with each other.

This is a physics engine running on your CPU, not your GPU.

The webgl window is run with your GPU and is extremely simple. Drawing a few dozen boxes is something graphics cards from 22 years ago would have no problem with.