Wasmtime Now Offering Go Bindings For WebAssembly On The Desktop

[Veto]

Well, startup is only a phase (altough very important) of the life of a program.

I prefer a Java application that takes a bit to start and then runs amazingly fast than a Python one that starts faster and then run slow as hell for all its duration.

Thanks for sharing your preferences. However, I think most users would prefer applications that starts fast and runs amazingly fast - while they really don't care what language is used to make it.

What Java applications do you know that runs amazingly fast? (I only know of Minecraft, which would somewhat fit in that category)

[TemplarGR]

TemplarGR
There will always be some overhead with non-native applications. Either during runtime or during start-up. No bytecode or Script language can possibly be as resource-efficient as a native language, since no interpreter or JIT compiler can execute in zero time.

This is not true. Yes there is some overhead and perhaps some additional start-up time but there are also many optimizations that can be done that can't be done to native languages and these things cancel each other out. Especially on modern hardware with large caches, many cores, and many pipelines per core.

[TemplarGR]

Ah so the JIT interpreter for Wasm bytecode must be really slow because that is native.

Everything has to run on bare metal at some point. The only difference is how many hoops the developer makes the computer jump through first .

I am kinda joking. Wasm is great. It allows me to stick with C and C++ on stupid platforms that favor niche languages. I will take the speed hit just to keep things correct.

Everything runs on metal. Literally every single line of code. Not everything is written on metal, but everything runs on it. It just runs through layers of translation.

Obviously bytecode has to be transformed to machine language at some point, as a cpu core can only run machine code and nothing else, not even assembly. It is not because of speed, it is because it literally can't be done otherwise, unless the cpu core itself has a bytecode ISA.

But since no one of us writes machine code, we have to rely on compilers and interpreters and libraries to write machine code for us. Assemblers, c compilers, wasm jit interpreters, and so on and so on. The problem is, even the best assemblers and c compilers can't do everything, can't optimize at the best possible capacity, and since compiled code has no access to runtime data, there are a lot of optimizations that can't be done in compiled code. They just can't be done.

In the end, on modern hardware, JIT bytecode can be virtually the same in speed because of those optimizations. And JIT bytecode doesn't have to run everything on bytecode, performance critical libraries can be written in C or assembly and utlized by bytecode software. For example JIT bytecode video games can be decent in performance because the OpenGL driver is written in C and Assembly, doesn't matter if the draw calls are from a bytecode game.

In the end, the added advantage of faster prototyping and code writting and code portability is worth any potential performance hit.

[dragorth]

Everything runs on metal. Literally every single line of code. Not everything is written on metal, but everything runs on it. It just runs through layers of translation.

Obviously bytecode has to be transformed to machine language at some point, as a cpu core can only run machine code and nothing else, not even assembly. It is not because of speed, it is because it literally can't be done otherwise, unless the cpu core itself has a bytecode ISA.

But since no one of us writes machine code, we have to rely on compilers and interpreters and libraries to write machine code for us. Assemblers, c compilers, wasm jit interpreters, and so on and so on. The problem is, even the best assemblers and c compilers can't do everything, can't optimize at the best possible capacity, and since compiled code has no access to runtime data, there are a lot of optimizations that can't be done in compiled code. They just can't be done.

In the end, on modern hardware, JIT bytecode can be virtually the same in speed because of those optimizations. And JIT bytecode doesn't have to run everything on bytecode, performance critical libraries can be written in C or assembly and utlized by bytecode software. For example JIT bytecode video games can be decent in performance because the OpenGL driver is written in C and Assembly, doesn't matter if the draw calls are from a bytecode game.

In the end, the added advantage of faster prototyping and code writting and code portability is worth any potential performance hit.

Which is it? Are byte-code video-games fast because most of it is compiled from C, or are they really the same speed?

The reality is, higher level languages are getting to be closer to the speed of byte-code, because of all the added abstractions. And video-games are written in C or low level C++ to eak out the performance most applications don't bother going for.

[Michael_S]

Personally, I hope to see as few web technologies on the desktop as possible. I strongly prefer native applications. Everything else is a waste of CPU cycles.

Apple, Google, and Microsoft between them effectively own all of consumer computing. We're never going to convince 100 million people to install Debian, or FreeBSD, or Arch Linux, or even de-Googled LineageOS.

WebAssembly/WASM might be the closest thing we have to an escape route. It's supported by all of the big browsers, it has sandboxing built in, the standard keeps getting new features added, and these native runtimes like wasmtime even allow it to be run without the overhead of a complete browser.

So every time a consumer switches from a native Windows/iOS/Android/macOS application to a WASM application, that consumer is one step closer to not needing a particular host operating system or application store. Even if most consumers never switch to Ubuntu or FreeBSD, even just being able to go from iOS to Android or ChromeOS to Windows without losing your favorite applications will greatly diminish the power wielded by Apple, Google, and Microsoft.

[Michael_S]

To continue my previous post: according to this article published last May, in a series of benchmarks C code running in WASM was on average 45-55% slower than native C code and at worst 2.5 times slower than native C code. https://arxiv.org/abs/1901.09056

That's still faster than most languages that aren't C, C++, or Rust. It adds a layer of memory safety guarantees and sandboxing. It's write-once-run-anywhere in a way that Java never actually managed to deliver. Cross-programming-language operation in WASM, like using a Go library from C++, is less effort than cross-programming-language operations with foreign function interfaces on native. Last, performance optimizations on these WASM runtimes are still being done so the performance gap with native will probably shrink further.

I find the argument that WebAssembly is the future of software pretty compelling. If anyone has better strategies from breaking the Google/Microsoft/Apple stranglehold on consumer computing, I'd love to hear it. (No sarcasm. I'm open to different ideas, this is just the best option I've seen.) It sure beats Electron-All-The-Things.

[cynic]

What Java applications do you know that runs amazingly fast? (I only know of Minecraft, which would somewhat fit in that category)

beside all the server side applications, I daily use IntelliJ Idea and JOSM on a 2012 thinkpad, and they run quite smoothly, altough they are full featured.
Another one is SQLDeveloper, but that one is so buggy that I wouldn't count as a good example
oh, and Minecraft too

[elvenbone]

I completely agree with your comment, but I have to critize the authors of that article:

according to this article published last May, in a series of benchmarks C code running in WASM was on average 45-55% slower than native C code and at worst 2.5 times slower than native C code. https://arxiv.org/abs/1901.09056

I hate when people in a supposedly scientific article use multiplication factors greater than 1 to quantify a decrease. We can only assume that they mean a demoninator that gives the resulting end performance (e.g. taking x times more computation time), assuming that a greater factor means a greater slowdown. (If it is the other way around the demoninator gives the loss of performance, then a greater factor means less slowdown which is even more nonsense).
If my assumption is correct, then their statements are unnecessary gibberish:

WebAssembly run slower by an average of 45% (Firefox) to 55% (Chrome), with peak slowdowns of 2.08x (Firefox) and 2.5x (Chrome).

1/2.08 would be a slowdown of 52%, a relative difference of 15% from the average 45%.
1/2.5 would be a slowdown of 60%, a relative difference of only 9% from the average 55%.
But a factor of 2 or even 2.5 sounds so much more significant than writing 60 next to 55... what great scientific writing!


EDIT:

I find the argument that WebAssembly is the future of software pretty compelling. If anyone has better strategies from breaking the Google/Microsoft/Apple stranglehold on consumer computing, I'd love to hear it. (No sarcasm. I'm open to different ideas, this is just the best option I've seen.) It sure beats Electron-All-The-Things.

I would have loved Qt to become a widely used open platform for multiple platforms, but given the recent events, I'm not so sure if that's good...

[cynical]

TemplarGR
There will always be some overhead with non-native applications. Either during runtime or during start-up. No bytecode or Script language can possibly be as resource-efficient as a native language, since no interpreter or JIT compiler can execute in zero time.

That's not true. A JIT compiled language can be as fast or even faster than native. Not at startup or "first run", but once the JIT kicks in, it is identical to native code (that's what it is compiling to), other than the fact that it can adapt to different runtime conditions.

[cynical]

Thanks for sharing your preferences. However, I think most users would prefer applications that starts fast and runs amazingly fast - while they really don't care what language is used to make it.

What Java applications do you know that runs amazingly fast? (I only know of Minecraft, which would somewhat fit in that category)

Nobody uses Java on the desktop anymore (apart from Minecraft). It has nothing to do with speed. It has to do with the fact that people find it more convenient to target the browser as a runtime and use applications delivered over HTTP, which require zero installation. If you look at server applications, there are plenty of Java applications that run fast.