6 ms·

In my opinion WebAssembly and all the in-browser applications are a waste of power. Please do a small experiment: make a 30 minutes video call on your laptop us

In my opinion WebAssembly and all the in-browser applications are a waste of power. Please do a small experiment: make a 30 minutes video call on your laptop using both: natively compiled skype and google meet. In my case meet drains almost 2x amount of power and after an hour-lasting meeting I have no battery left, but on one-hour meeting on skype I still have 56% of battery. It's because you cannot have native performance on something that is still the virtual machine. Another reservation I have is global migrate-to-the-cloud trend, where I can see heavy-CPU programs like adobe photoshop moving to in-browser, while I feel much more comfortable using natively compiled applications. It's just faster and gives working smoothness feeling. Also when I have a locally installed photoshop or lightroom, nobody requires any money from me. I can have a dedicated laptop for my photos processing, and nobody will take it from me, because I didn't pay for the next month. However this is another story of making people dependant on subcriptions in all cases of our lives...

paulgb 3y ago
> Please do a small experiment: make a 30 minutes video call on your laptop using both: natively compiled skype and google meet. I don't think this is a Wasm issue. IIRC Google Meet uses WebRTC for encoding, which is the compute-heavy part of a video call. They might use Wasm for background blurring or something like that. In general I suspect that the issue here is that Skype as a native app can access some video-specific hardware acceleration that the browser can't. CPU-bound workloads should be close to native speed (OP says within 10% of native which tracks with my experience)
- saiya-jin 3y ago
  I agree, virtualization layers always add a bit of overhead by principle, but in 2023 we use plenty of those and the hit is small enough to ignore it for most uses. Either some bad coding/lib dependencies or lack of direct access to better hardware as you mention, but then browsers should allow this, with some good permission process.
  - paulgb 3y ago
    > but then browsers should allow this Agreed! Between WebCodecs and WebGPU compute shaders, I think we’re getting closer to this ideal.
- rjsw 3y ago
  WebRTC can use hardware offload for video decoding, at least in Firefox.
  - lxgr 3y ago
    Even that is both browser and OS dependent, in my experience.
- doctorpangloss 3y ago
  The user writing: > In my case meet drains almost 2x amount of power and after an hour-lasting meeting I have no battery left, but on one-hour meeting on skype I still have 56% of battery. is comparing apples to oranges via an uncontrolled comparison. > WebRTC for encoding, which is the compute-heavy part of a video call On Windows in Chrome, Google Meet will correctly use the same hardware acceleration for video encoding that Skype does. Both will ultimately use DXVA on modern hardware. On macOS, the story is complicated and I know less about Skype's internals.
  - chii 3y ago
    > comparing apples to oranges it is because the laymen simply doesn't know how to account for their own bias. They conceived an experiment to try to show an objective truth, but was in fact biased - and probably didn't even really know it. This is why science isn't done this way; you need to put in a lot of effort to design the experiment, so that preconceived biases don't show up. Things like double blind, and randomization, etc.
3cats-in-a-coat 3y ago
It is a waste of power (currently). But you can have native performance on a virtual machine by translating your VM code to machine code and just running the machine code. There are ways to sandbox without interpretation. WASM goes to some extent in that direction, but not all the way, mostly for safety. So it wastes some power. The question is: so what? WASM is attractive because it's an instant deployment. You open a URL, boom. Nothing to explicitly download, install and launch. Nothing to maintain. And eventually uninstall. It removes the friction for apps you use once in a while, or... just once, even. In engineering & design, efficiency comes in many kinds. You waste power on the user's machine, but you got your foot in the doorstep by them opening your URL and running your app. It's not how many of us, including me, want the world to be, but it... be how it be. P.S.: The real flip-side is when sites start figuring out ways en masse to profit from your compute by visiting their sites. Crypto mining as one example. Oh well.
- AlotOfReading 3y ago
  You don't get "native performance" (as in the speed that a native application would run) even with JIT. You still need to implement the semantics of the virtual machine, and generate the native code, add safety guardrails for memory safety, etc. The Hotspot JVM is a world class implementation that does all of that well and still loses to C/C++ outside specialized benchmarks.
  - kaba0 3y ago
    The JVM has different semantics than C/C++, so it is not an apt comparison. Asymptotical performance-wise there is nothing inherent with a JIT compiler that would put it behind an AOT one.
kaba0 3y ago
> It's because you cannot have native performance on something that is still the virtual machine JIT compilers are a thing, so this statement is just plain false. Also, apples to oranges comparison. I’m not saying that in this particular case it is not true, but that can’t be deduced from this datapoint.
- fredrikholm 3y ago
  > JIT compilers are a thing, so this statement is just plain false. Do you know of any JITed languages that approach SIMD optimized native code in terms of performance and overhead? Even the best ones (eg. LuaJIT) fail to come close to even moderately optimized C code, with much higher memory usage. On top of that, JIT optimizations don't always trigger and you fall back to interpreted levels, which are orders of magnitude more expensive.
  - kaba0 3y ago
    Why would LuaJIT be the best? I’m fairly sure that V8 and HotSpot that had million times more dev time spent on are way better on every front. And autovectorization is definitely done by HotSpot (I would guess also by V8, though not sure), but autovectorization in itself is very finicky both AOT and JIT, so there is now a stronger move towards user-exposed controls, e.g. Java’s new Vector API, but C# also had something like that for years. Funnily enough, C doesn’t have any standard way to control vectorization, only compiler-specific extensions. Also, memory layout is a completely different problem space, don’t judge JIT compilers on that. On numerical code they are very competitive with AOT compiled, low-level languages, both JavaScript and Java. Of course if a given object could not be escape analyzed than the semantics doesn’t allow further inlining and somewhere that pointer indirection have to be paid, but don’t forget that besides benchmarks, most real life code in C/C++/Rust whatever will also happily chase pointers, so the difference is again, not as stark as some benchmark may tell you. Also, this is more related to GC+JITted languages, but are not necessary for JIT alone. With that said, I just realized that there is Julia in this exact niche, that also demonstrates my point very well. > On top of that, JIT optimizations don't always trigger and you fall back to interpreted levels, which are orders of magnitude more expensive. An optimization “triggering” is exactly similar to what an AOT compiler would do, only with a smaller time/resource budget. What you are getting at - speculative optimizations - are a different story, and are not a necessity in case of a JIT. And they get deoptimized when the assumptions they made for the optimization are proven incorrect (e.g. in java’s case virtual calls may have been replaced by static ones as only a single class implementing the given interface were loaded at the time - but upon loading a new implementation this will have to be deoptimized). You are right that deoptimizations can be expensive, when they go wrong, or in the worst case go into some cycles, but in practice with V8/HotSpot, these work well enough. The initial warmup is more likely to cause some jitter if any.
unnouinceput 3y ago
Skype is an Electron app currently. If you think current Skype is the better performer imagine the old Skype that was truly native.
- p0w3n3d 3y ago
  i'm not talking about GUI but rather the camera/picture processing. Yes, I know that electron is fast, I have very good experience with VSCode, which is maybe even faster than "native" Idea in Java, however IDEA does much more for me, so can't really compare. Maybe I'm too old fashioned, I don't know. What I know is that creating multiplatform native application is really hell (I did that), and Javascript is much cheaper, that's why everyone is doing electron, which literally launches up another separate google chrome in your memory... Yes, it's cheaper, but memory is much more expensive nowadays, than it used to be when I started programming...
  - lxgr 3y ago
    > i'm not talking about GUI but rather the camera/picture processing. That's usually done by the browser when using WebRTC (except for postprocessing, e.g. background blur), not the application (using WASM or JavaScript). Some browsers do this in hardware, others don't – just like some native videoconferencing applications are horrible CPU hogs, and others are quite efficient.
flohofwoe 3y ago
FWIW, the performance of my emulators [0] (mostly integer bit twiddling code written in 'portable C') is pretty much identical in the browser and natively compiled version (within around 25% of each other). Of course one could go farther by using cpu- and compiler-specific optimizations (for instance SIMD intrinsics), but some of those are also portable to WASM. In general, memory layout optimizations translate directly to the WASM linear heap, and that's by far the most important performance factor before it makes sense to look into platform-specific optimizations. [0] https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/
- jcelerier 3y ago
  ... 25% ? I'd sell my soul for a computer that's single-thread 25% faster than what we have right now
  - flohofwoe 3y ago
    Any code in interactive applications needs to have wiggle room to allow for a much greater variation in performance than 25% anyway, WASM will just "hit the wall" slightly earlier. If macOS decides to run your code on an efficiency core or a mobile device throttles the clock to avoid overheating, you'll lose a lot more performance than just 25%. Or if some users have a lower end device, or you use different compilers for different target platforms, or a new hardware exploit hits and the mitigation results in a general performance loss. The only situation where such 'wiggle room' isn't required is when you completely control the environment your code runs in, but in this case you don't need runtime portability nor safety, and thus WASM wouldn't make sense in the first place.
jauntywundrkind 3y ago
The clutching of pearls here is not going to change things in the slightest. I personally have pretty bad battery drain from Zoom. I think there's definitely a lot of futures where WebCodecs (for even better hardware accelerated encoding) & WebTransport & Media-over-QUIC open up technical paths to dominate & crush most native app implementations. And unlike native apps, which rely on mountains of proprietary systems, the web can be a platform where anyone can put together new ideas quickly & easily, that leverage enormously advanced common platforms. I am just so tired of all the web whining. None of these people have the faintest clue what the web is moving towards, have the slimmest interest in understanding why their gripes are actively being made irrelevant. It's brutal, enduring such strong & wrong anti-vision, having to forever be handling these very loud persistent minorities whose motto is, to quote the band Kula Shaker, "whatever it is I'm against it".
fidotron 3y ago
This is highly likely to be Google Meet using CODECs (like VP8/9) where the hardware acceleration is nothing like as well developed (read available or power efficient) as the h26x series, which Google are resistant to for licensing reasons. They also like doing simulcast, where the burden of encoding different stream resolutions for different end clients is performed at the sender end, when others do this transcoding in the cloud. Edit: Meet also apparently uses MediaPipe, which in browser does results in heavy WASM/GPU usage which on a native API could go to a NN accelerator instead. It is fair to say that stuff can melt batteries too.
nuc1e0n 3y ago
There is the hope that in time webassembly can and will be implemented directly in silicon.
- euroderf 3y ago
  One might think this would have emerged from some university-level fab already !

paulgb 3y ago

> Please do a small experiment: make a 30 minutes video call on your laptop using both: natively compiled skype and google meet. I don't think this is a Wasm issue. IIRC Google Meet uses WebRTC for encoding, which is the compute-heavy part of a video call. They might use Wasm for background blurring or something like that. In general I suspect that the issue here is that Skype as a native app can access some video-specific hardware acceleration that the browser can't. CPU-bound workloads should be close to native speed (OP says within 10% of native which tracks with my experience)

saiya-jin 3y ago
I agree, virtualization layers always add a bit of overhead by principle, but in 2023 we use plenty of those and the hit is small enough to ignore it for most uses. Either some bad coding/lib dependencies or lack of direct access to better hardware as you mention, but then browsers should allow this, with some good permission process.
- paulgb 3y ago
  > but then browsers should allow this Agreed! Between WebCodecs and WebGPU compute shaders, I think we’re getting closer to this ideal.
rjsw 3y ago
WebRTC can use hardware offload for video decoding, at least in Firefox.
- lxgr 3y ago
  Even that is both browser and OS dependent, in my experience.
doctorpangloss 3y ago
The user writing: > In my case meet drains almost 2x amount of power and after an hour-lasting meeting I have no battery left, but on one-hour meeting on skype I still have 56% of battery. is comparing apples to oranges via an uncontrolled comparison. > WebRTC for encoding, which is the compute-heavy part of a video call On Windows in Chrome, Google Meet will correctly use the same hardware acceleration for video encoding that Skype does. Both will ultimately use DXVA on modern hardware. On macOS, the story is complicated and I know less about Skype's internals.
- chii 3y ago
  > comparing apples to oranges it is because the laymen simply doesn't know how to account for their own bias. They conceived an experiment to try to show an objective truth, but was in fact biased - and probably didn't even really know it. This is why science isn't done this way; you need to put in a lot of effort to design the experiment, so that preconceived biases don't show up. Things like double blind, and randomization, etc.

3cats-in-a-coat 3y ago

It is a waste of power (currently). But you can have native performance on a virtual machine by translating your VM code to machine code and just running the machine code. There are ways to sandbox without interpretation. WASM goes to some extent in that direction, but not all the way, mostly for safety. So it wastes some power. The question is: so what? WASM is attractive because it's an instant deployment. You open a URL, boom. Nothing to explicitly download, install and launch. Nothing to maintain. And eventually uninstall. It removes the friction for apps you use once in a while, or... just once, even. In engineering & design, efficiency comes in many kinds. You waste power on the user's machine, but you got your foot in the doorstep by them opening your URL and running your app. It's not how many of us, including me, want the world to be, but it... be how it be. P.S.: The real flip-side is when sites start figuring out ways en masse to profit from your compute by visiting their sites. Crypto mining as one example. Oh well.

AlotOfReading 3y ago
You don't get "native performance" (as in the speed that a native application would run) even with JIT. You still need to implement the semantics of the virtual machine, and generate the native code, add safety guardrails for memory safety, etc. The Hotspot JVM is a world class implementation that does all of that well and still loses to C/C++ outside specialized benchmarks.
- kaba0 3y ago
  The JVM has different semantics than C/C++, so it is not an apt comparison. Asymptotical performance-wise there is nothing inherent with a JIT compiler that would put it behind an AOT one.

kaba0 3y ago

> It's because you cannot have native performance on something that is still the virtual machine JIT compilers are a thing, so this statement is just plain false. Also, apples to oranges comparison. I’m not saying that in this particular case it is not true, but that can’t be deduced from this datapoint.

fredrikholm 3y ago
> JIT compilers are a thing, so this statement is just plain false. Do you know of any JITed languages that approach SIMD optimized native code in terms of performance and overhead? Even the best ones (eg. LuaJIT) fail to come close to even moderately optimized C code, with much higher memory usage. On top of that, JIT optimizations don't always trigger and you fall back to interpreted levels, which are orders of magnitude more expensive.
- kaba0 3y ago
  Why would LuaJIT be the best? I’m fairly sure that V8 and HotSpot that had million times more dev time spent on are way better on every front. And autovectorization is definitely done by HotSpot (I would guess also by V8, though not sure), but autovectorization in itself is very finicky both AOT and JIT, so there is now a stronger move towards user-exposed controls, e.g. Java’s new Vector API, but C# also had something like that for years. Funnily enough, C doesn’t have any standard way to control vectorization, only compiler-specific extensions. Also, memory layout is a completely different problem space, don’t judge JIT compilers on that. On numerical code they are very competitive with AOT compiled, low-level languages, both JavaScript and Java. Of course if a given object could not be escape analyzed than the semantics doesn’t allow further inlining and somewhere that pointer indirection have to be paid, but don’t forget that besides benchmarks, most real life code in C/C++/Rust whatever will also happily chase pointers, so the difference is again, not as stark as some benchmark may tell you. Also, this is more related to GC+JITted languages, but are not necessary for JIT alone. With that said, I just realized that there is Julia in this exact niche, that also demonstrates my point very well. > On top of that, JIT optimizations don't always trigger and you fall back to interpreted levels, which are orders of magnitude more expensive. An optimization “triggering” is exactly similar to what an AOT compiler would do, only with a smaller time/resource budget. What you are getting at - speculative optimizations - are a different story, and are not a necessity in case of a JIT. And they get deoptimized when the assumptions they made for the optimization are proven incorrect (e.g. in java’s case virtual calls may have been replaced by static ones as only a single class implementing the given interface were loaded at the time - but upon loading a new implementation this will have to be deoptimized). You are right that deoptimizations can be expensive, when they go wrong, or in the worst case go into some cycles, but in practice with V8/HotSpot, these work well enough. The initial warmup is more likely to cause some jitter if any.

unnouinceput 3y ago

Skype is an Electron app currently. If you think current Skype is the better performer imagine the old Skype that was truly native.

p0w3n3d 3y ago
i'm not talking about GUI but rather the camera/picture processing. Yes, I know that electron is fast, I have very good experience with VSCode, which is maybe even faster than "native" Idea in Java, however IDEA does much more for me, so can't really compare. Maybe I'm too old fashioned, I don't know. What I know is that creating multiplatform native application is really hell (I did that), and Javascript is much cheaper, that's why everyone is doing electron, which literally launches up another separate google chrome in your memory... Yes, it's cheaper, but memory is much more expensive nowadays, than it used to be when I started programming...
- lxgr 3y ago
  > i'm not talking about GUI but rather the camera/picture processing. That's usually done by the browser when using WebRTC (except for postprocessing, e.g. background blur), not the application (using WASM or JavaScript). Some browsers do this in hardware, others don't – just like some native videoconferencing applications are horrible CPU hogs, and others are quite efficient.

flohofwoe 3y ago

FWIW, the performance of my emulators [0] (mostly integer bit twiddling code written in 'portable C') is pretty much identical in the browser and natively compiled version (within around 25% of each other). Of course one could go farther by using cpu- and compiler-specific optimizations (for instance SIMD intrinsics), but some of those are also portable to WASM. In general, memory layout optimizations translate directly to the WASM linear heap, and that's by far the most important performance factor before it makes sense to look into platform-specific optimizations. [0] https://floooh.github.io/tiny8bit/ https://floooh.github.io/tiny8bit/

jcelerier 3y ago
... 25% ? I'd sell my soul for a computer that's single-thread 25% faster than what we have right now
- flohofwoe 3y ago
  Any code in interactive applications needs to have wiggle room to allow for a much greater variation in performance than 25% anyway, WASM will just "hit the wall" slightly earlier. If macOS decides to run your code on an efficiency core or a mobile device throttles the clock to avoid overheating, you'll lose a lot more performance than just 25%. Or if some users have a lower end device, or you use different compilers for different target platforms, or a new hardware exploit hits and the mitigation results in a general performance loss. The only situation where such 'wiggle room' isn't required is when you completely control the environment your code runs in, but in this case you don't need runtime portability nor safety, and thus WASM wouldn't make sense in the first place.

jauntywundrkind 3y ago

The clutching of pearls here is not going to change things in the slightest. I personally have pretty bad battery drain from Zoom. I think there's definitely a lot of futures where WebCodecs (for even better hardware accelerated encoding) & WebTransport & Media-over-QUIC open up technical paths to dominate & crush most native app implementations. And unlike native apps, which rely on mountains of proprietary systems, the web can be a platform where anyone can put together new ideas quickly & easily, that leverage enormously advanced common platforms. I am just so tired of all the web whining. None of these people have the faintest clue what the web is moving towards, have the slimmest interest in understanding why their gripes are actively being made irrelevant. It's brutal, enduring such strong & wrong anti-vision, having to forever be handling these very loud persistent minorities whose motto is, to quote the band Kula Shaker, "whatever it is I'm against it".

fidotron 3y ago

This is highly likely to be Google Meet using CODECs (like VP8/9) where the hardware acceleration is nothing like as well developed (read available or power efficient) as the h26x series, which Google are resistant to for licensing reasons. They also like doing simulcast, where the burden of encoding different stream resolutions for different end clients is performed at the sender end, when others do this transcoding in the cloud. Edit: Meet also apparently uses MediaPipe, which in browser does results in heavy WASM/GPU usage which on a native API could go to a NN accelerator instead. It is fair to say that stuff can melt batteries too.

nuc1e0n 3y ago

There is the hope that in time webassembly can and will be implemented directly in silicon.

euroderf 3y ago
One might think this would have emerged from some university-level fab already !