How WebAssembly Changes Software Distribution • Hacker News Board

Re: How WebAssembly Changes Software Distribution

#61

Post by wenc » Wed, Sep 09, 2020, 9:01 PM UTC

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.

Just tried the pizza shop example on my desktop. Linux x86-64 (i7 quad core, 8GB RAM, Firefox 80.0.1)

FF memory usage: blank page = 285MB, peak = 839MB, steady-state = 340MB. Load time: ~6s wall clock time.

Tried it with my Windows 10 Desktop too (i7 quad core, 32GB RAM, Firefox 80.0.1).

FF memory usage: blank page = 215MB, peak = 1015MB, steady-state = 658MB. Load time: ~3s wall clock time.

Once loaded, the UI was very responsive.

Re: How WebAssembly Changes Software Distribution

#62

Post by wenc » Wed, Sep 09, 2020, 9:33 PM UTC

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…

Microsoft is betting on (the not yet mature) Blazor [1,2] framework for porting .NET applications to WASM. Here's a CRUD app WASM example [3] -- there's an initial load time, but once loaded the app seems pretty responsive. There's a bunch more demos here [4] to get a sense of the performance.

There's even a HN clone built on Blazor [5]. This very thread can be found there.

[1] https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

[2] https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2...

[3] https://becksblazor.azurewebsites.net

[4] https://github.com/StevenTCramer/awesome-blazor#samples-and-...

[5] http://blazorhackernews.surge.sh

Re: How WebAssembly Changes Software Distribution

#63

Post by Rochus » Wed, Sep 09, 2020, 10:11 PM UTC

wenc wrote: post #61

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.

Just tried the pizza shop example on my desktop. Linux x86-64 (i7 quad core, 8GB RAM, Firefox 80.0.1) FF memory usage: blank page = 285MB, peak = 839MB, steady-state = 340MB. Load time: ~6s wall clock time. Tried it with my Windows 10 Desktop too (i7 quad core, 32GB RAM, Firefox 80.0.1). FF memory usage: blank page = 215MB, peak = 1015MB, steady-state = 658MB. Load time: ~3s wall clock time. Once loaded, the UI was v…

Thanks for the measurements. That's much faster indeed than on my laptop and even quite decent (besides the peak memory use). Compared to the C++ native version of similar apps on my Linux i386 and Windows x86 this is about factor 10/20 (Linux/Windows) more RAM in steady state and factor 25/30 (Linux/Windows) in peak. Start time of the C++ apps (not QML) is factor 6/3 (Linux/Windows) slower.

Btw. I noticed that on my machine memory use is higher on Chromium and performance even worse than with Firefox. So it seems to depend on browser type/version, and someone in this thread said that there is no support for Safari.

Re: How WebAssembly Changes Software Distribution

#64

Post by JoshTriplett » Wed, Sep 09, 2020, 10:59 PM UTC

CyberDildonics wrote: post #58

JoshTriplett wrote: post #57

Earlier quoted context omitted.

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?

This subthread started because two people saw wildly different performance for the same demo, and some attributed that to wasm. My point was that given that the demo seems heavily dependent on graphics performance, it's unlikely that the observed performance differences had anything to do with wasm.

Re: How WebAssembly Changes Software Distribution

#65

Post by 7786655 » Wed, Sep 09, 2020, 11:09 PM UTC

pmoriarty wrote: post #49

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 h…

It won't because WASM applications still use the DOM.

In theory it could push everything through a , but that can be done in JS as well and doesn't seem to be that common.

Re: How WebAssembly Changes Software Distribution

#66

Post by sunnyP » Thu, Sep 10, 2020, 1:38 AM UTC

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.

This demo with a Virtualization component looks promising for large amounts of data.

https://youtu.be/KRNd8JDRqRc?t=3049

Re: How WebAssembly Changes Software Distribution

#67

Post by CyberDildonics » Thu, Sep 10, 2020, 2:27 AM UTC

JoshTriplett wrote: post #64

CyberDildonics wrote: post #58

Earlier quoted context omitted.

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?

This subthread started because two people saw wildly different performance for the same demo, and some attributed that to wasm. My point was that given that the demo seems heavily dependent on graphics performance, it's unlikely that the observed performance differences had anything to do with wasm.

The demo is just a few boxes, it is not graphics limited. A 4k webgl window might have some sort of bottleneck in your web browser, drivers or gpu. The demo is a physics simulation though. I don't know why you would create a situation where anything would slow down on your computer while having nothing to do with CPU speed and then talk about it in a thread about webasm.

Re: How WebAssembly Changes Software Distribution

#68

Post by megameter » Thu, Sep 10, 2020, 9:41 AM UTC

CyberDildonics wrote: post #67

JoshTriplett wrote: post #64

Earlier quoted context omitted.

This subthread started because two people saw wildly different performance for the same demo, and some attributed that to wasm. My point was that given that the demo seems heavily dependent on graphics performance, it's unlikely that the observed performance differences had anything to do with wasm.

The demo is just a few boxes, it is not graphics limited. A 4k webgl window might have some sort of bottleneck in your web browser, drivers or gpu. The demo is a physics simulation though. I don't know why you would create a situation where anything would slow down on your computer while having nothing to do with CPU speed and then talk about it in a thread about webasm.

It doesn't matter how many boxes there are if the shaders run in software, which is going to be the case on really old integrated graphics.

Re: How WebAssembly Changes Software Distribution

#69

Post by CyberDildonics » Thu, Sep 10, 2020, 2:05 PM UTC

megameter wrote: post #68

CyberDildonics wrote: post #67

Earlier quoted context omitted.

The demo is just a few boxes, it is not graphics limited. A 4k webgl window might have some sort of bottleneck in your web browser, drivers or gpu. The demo is a physics simulation though. I don't know why you would create a situation where anything would slow down on your computer while having nothing to do with CPU speed and then talk about it in a thread about webasm.

It doesn't matter how many boxes there are if the shaders run in software, which is going to be the case on really old integrated graphics.

I'm not sure why anyone would think it makes sense to use a computer so ancient it can't run webgl and then use that to talk about webasm not being fast on a webgl demo.