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

31–40 of 69 posts

Re: How WebAssembly Changes Software Distribution

#31

Post by raxxorrax »

jkelleyrtp wrote: post #21
Rochus wrote: post #18

Earlier quoted context omitted.

To quote from https://webassembly.org/ : "Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications." So did they mean only GUI-less client applications? EDIT: also e.g. this source https://developer.mozilla.org/en-US/docs/WebAssembly/Concept... makes it clear that porting e.g. C++ GUI applications is an intended feature, not just a…

Browser API calls add 1us of overhead. If your code is conscious of this, then it won’t be a problem. Much of the thought process behind react is to update the dom as little as possible, because it usually takes a while to repaint. Similarly, your WASM code will have this small overhead, but even 1000 calls is just 1ms. Regardless, there is still much more performance gains to be had by WASM-compatible languages when…

Looks like a nice physics engine, but I wouldn't say it blows JS engines out of the water performance wise. They are surprisingly fast these days.

Ammo js: http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.ht...

Ammo wasm: http://kripken.github.io/ammo.js/examples/webgl_demo/ammo.wa...

They can be faster, but it is still insane how fast JS interpreters have become. So for smaller application it might be ok to stay in JS land.

Re: How WebAssembly Changes Software Distribution

#32

Post by joshum97 »

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.

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.

Re: How WebAssembly Changes Software Distribution

#33

Post by CyberDildonics »

Rochus wrote: post #28
CyberDildonics wrote: post #25

Earlier quoted context omitted.

> low performance and the enormous memory consumption That has not been what I've seen from it. People have made video editors and ported game into web pages. You make a lot of claims in this thread about speed and memory but don't back any of them up.

Here are some examples: https://www.qt.io/qt-examples-for-webassembly ; some of them don't even start on my 32 bit machine because more than 2GB RAM would need to be allocated. EDIT: I'm using Firefox 78.0.2 on Linux i386.

These load in about 1 second for me and everything is almost instant and fluid on firefox 80. The firefox process running them uses 284MB of memory.

Re: How WebAssembly Changes Software Distribution

#34

Post by jdhbbbhb »

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.

Webassembly is not designed to replace javascript. It works along side it.

Re: How WebAssembly Changes Software Distribution

#35

Post by joshum97 »

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…

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.

Re: How WebAssembly Changes Software Distribution

#36

Post by Rochus »

CyberDildonics wrote: post #30
Rochus wrote: post #26

Earlier quoted context omitted.

Thanks for the link. I tried the cubes 3d demo which takes about 45 seconds on my laptop until no cube moves anymore (around step 590); probably not the expected performance; if I find time I will run the Rust version locally.

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.

Re: How WebAssembly Changes Software Distribution

#37

Post by Rochus »

CyberDildonics wrote: post #33
Rochus wrote: post #28

Earlier quoted context omitted.

Here are some examples: https://www.qt.io/qt-examples-for-webassembly ; some of them don't even start on my 32 bit machine because more than 2GB RAM would need to be allocated. EDIT: I'm using Firefox 78.0.2 on Linux i386.

These load in about 1 second for me and everything is almost instant and fluid on firefox 80. The firefox process running them uses 284MB of memory.

On which OS? Have you watched peak memory use, or is this steady state?

Re: How WebAssembly Changes Software Distribution

#38

Post by joshum97 »

MayeulC wrote: post #22

I am wondering if it would be a huge project to create an "http server" kind of Wasm binary. With php, rails or whatever server-side scripting a given project is using. I guess it would still require some quite extensive changes to the served HTML and js. My use-case would be to create single instances of a server-side project, for demonstration purposes, or serverless operation. Things like providing a webapp for ht…

Does Lucet (https://www.fastly.com/blog/announcing-lucet-fastly-native-w...) meet those needs?

Re: How WebAssembly Changes Software Distribution

#39

Post by johncolanduoni »

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…

The packages would have to settle on a stable ABI. This is virtually impossible for Rust (which has no ABI stability between binaries compiled with different compiler versions).

Unfortunately this doesn’t get you much in the way of safety guarantees either, since you can’t readily run these packages in separate WASM instances; Rust, C++, C etc. all assume a shared linear memory when linking.

I’m bullish on WASM in general but I think WASM for simplifying package management or for writing executables that just need restricted filesystem access is a solution in search of a problem. Various containerization efforts have solved most of the important problems here with less runtime and toolchain overhead.

Re: How WebAssembly Changes Software Distribution

#40

Post by Jasper_ »

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.

I've rewritten hot loops (decompression & texture detiling) from JavaScript into specialized AssemblyScript and seen a decent (2-3x) perf boost? I'm not sure how much of that is "running hot" in JS, since in the examples back then I was probably only doing it for ~100 textures. I can't imagine beating JS with a giant STL-using app with a clang-based toolchain, but the AOT nature helps a lot for hot loops; the kind of stuff you'd write custom asm for in a game engine.

Of course I was making sure to do as minimal memory transfer as possible, and I already use a lot of weird patterns to try to minimize GC in JS.

https://github.com/magcius/noclip.website/blob/master/src/gx...

https://github.com/magcius/noclip.website/blob/master/src/as...

Post reply on HN