Hacker News Reader

Comment by Octoth0rpe | Hacker News Reader

Tl;dr: 2x slower in FF, 2.5x slower in chrome. Depending on the application, that doesn't seem to be a huge tradeoff. Certainly many developers are comfortable writing things in python, which is likely hundreds of times slower than C++ in many problem spaces.

TBH though my big hope for web assembly has nothing to do with the web at all, but as a distribution format for drivers that can be installed on any cpu arch/kernel. Finally, my dream of BSD on risc-v is achieved! ....or more likely, just running linux on arm.

View on HN

"Certainly many developers are comfortable writing things in python,"

But python is a high level script language with gc. WebAssembly is very lowlevel, so the people who could and would write in python will not write in wasm and also not in C.

Wasm is still awesome, it is just not, what many hope it will be. And a distribution format for drivers? Well, I am not a low level expert, but that seems very unlikely to work out, from what I understand.

The point is that people are clearly willing to leave magnitudes of performance on the table just so that they can use their language of choice.

That's what Webassembly enables today: You can use C/C++, Rust, Go and several others. Of course the ecosystem is not as mature. Languages with a big runtimes aren't good candidates for lean web apps. Performance isn't the dealbreaker though.

"people are clearly willing to leave magnitudes of performance on the table just so that they can use their language of choice"

Certainly. It also makes sense, as programmers time is usually worth much more than computing time.

I hate to break it to you, but I Java didn’t do this for you I don’t think WebAssembly is going to either. :-/

Globally compatible drivers is a pipedream, because the problem is not that the machine architecture is different but that the API they interact with is fundamentally different. Unless everyone agrees on some sort of standard like NDIS, but Linux has more or less promised never to have a stable API.

well sure, but in this hypothetical future, someone has added the ability to load wasm files as drivers, and the API that that functionality exposes _could_ be stable.

You don't mind drivers being half as performant as they were before, with the only benefit being they're easier to distribute? Why? How is that beneficial to anyone except the person packaging the driver?

The browser is a really good sandbox. The security of browsers is also what makes web apps easy to distribute.

That said I don't see the point of writing drivers in webassembly. If you want better security for drivers, there are better endeavors like microkernel architectures which Linux still isn't using.

> You don't mind drivers being half as performant as they were before, with the only benefit being they're easier to distribute?

A different way of phrasing this would be "would you prefer a driver that uses 2% of your cpu vs no driver at all? Note that if the hypothetical non-existent driver was written in c, it would only take 1% of your cpu"

> Why?

Because the alternative for many alternative OSes is no driver at all.

> How is that beneficial to anyone except the person packaging the driver?

Because if it's more convenient for the packager, then there's a better chance that they'll package a driver that way, which means I'm more likely to actually get the driver in the first place.

Are drivers actually being written in WASM? In Windows, drivers often require kernel-space code, which require a higher level interrupt request level (IRQL). Incorrect dependencies in IRQL are the leading cause of BSOD[0]. If WASM got this right, it would be impressive. It also might mean that compromising the sandbox is Very Dangerous.

[0] IRQL exception was at least the leading cause when I was a Core OS developer for Windows.

A difference to Python is that Python has the escape hatch with native modules. A PyQt application as arbitrary example relies on native code for doing most of the handling and only some small parts of business logic have to be done in Python. With WebAssembly the Qt stuff is compiled to WebAssembly as well and therefore suffers from the slowdown as well. Only the actual rendering can be offloaded to WebGL and hardware. (Still we were able to write snappy UIs more than a decade ago, where systems were a lot slower so for many cases that should be fine)

Yeah, I'd say that it's actually pretty good result. Too bad that the benchmark doesn't include any non-browser WASM runtimes, like Wasmtime or Wasmer.

Reply on news.ycombinator.com