Wasmer 4.0 WebAssembly Implementation Brings WASIX Support

[phoronix]

Phoronix: Wasmer 4.0 WebAssembly Implementation Brings WASIX Support

Wasmer is an open-source WebAssembly implementation that is focused on running sandboxed applications everywhere thanks to the power of WASM while being as performant as traditional native applications. Today marks the availability of Wasmer 4.0 as another step forward for this project...

https://www.phoronix.com/news/Wasmer-4.0

[oleid]

So now we have WASIX in place, all that is missing is integrated windowing support and we're back to "write once, run everywhere", just without integrated garbage collector. Interesting how history is repeating itself over and over. 🤔

Jokes aside, I really like wasm for adding portable and sand-boxed plug-ins to my native applications. Currently, there is a performance hit for numerical stuff due to missing vectorization, however, there is vectorization support planned, AFAIR.

[dreamcat4]

it's a great project and hope it continues to become more relevant / accessible to more developers to meet their goals

[ddriver]

WebAssembly is great - it allows you to run C and C++ code at an abysmal performance in humanity's most bloated, buggy and insecure environment - a web browser. An awesome idea through and through. I've always been wondering, what can we do to make c/pp applications run worse, so that the other languages feel better about themselves...

Also, very necessary, because web browsers are that much more common than native compilers. There are so many platforms which can run a browser and don't even have a a native c compiler...

[oleid]

WebAssembly is great - it allows you to run C and C++ code at an abysmal performance

Technically, it doesn't have to be slower. Yet, the wasm-> native step when loading a web page is designed to be fast, not very optimizing. And most certainly, the lack of vectorization is a problem.

https://00f.net/2023/01/04/webassembly-benchmark-2023/

[ddriver]

Technically, it doesn't have to be slower. Yet, the wasm-> native step when loading a web page is designed to be fast, not very optimizing. And most certainly, the lack of vectorization is a problem.

https://00f.net/2023/01/04/webassembly-benchmark-2023/

Neat, perf hit only in the range of 50 to 500 %. Plus the various limitations of the runtime.

Ignoring this, when using the fastest runtime, WebAssembly was only about 2.32 times slower (median) than native code with architecture-specific optimizations. Not bad!

Only! Not bad! 232% is negligible. I am sure people who share this opinion wouldn't mind having their salary reduced by 2.32x.

It's funny with all the work that has been put to optimize every last %, where 20% is considered very healthy generational upgrade, and multi billion dollar companies double their CPUs power usage to get another 10% of performance... that we can so casually write off in excess of 200% performance for an absurdity of a mindless "convenience".

Sorry but "only" doesn't extend beyond maybe 5% performance penalty. 200+% on average IS indeed abysmal. Yes, there's clearly much worse too, but that don't make the penalty any lesser, and seems like a very silly price to pay so you can run your code in a bloated, buggy slow and limited environment, where you can easily target the platform with an optimal native binary.

[coder]

WebAssembly is great - it allows you to run C and C++ code at an abysmal performance in ... a web browser.

People have long been compiling C and C++ code to Javascript, as a way of running it in a web browser. For them, this is a marked improvement.

what can we do to make c/pp applications run worse, so that the other languages feel better about themselves...

If you're having to run some closed-source x86 stuff on an ARM or RISC-V CPU, maybe you'd look upon these developments rather more positively. If WASM were ubiquitous, then the software ecosystem wouldn't be as biased towards entrenched ISAs.

[coder]

Technically, it doesn't have to be slower. Yet, the wasm-> native step when loading a web page is designed to be fast, not very optimizing.

Profile-guided optimization is the solution.

1. Load the page quickly, using the equivalent of -O0 or -O1.
2. In the background, recompile at -O2, using branch statistics from running the initial build.
3. Patch large subtrees in the callgraph, as the optimization pass for them completes.
4. Cache the results of #2, so if the program is ever reloaded, the optimized version is immediately used.

[coder]

Only! Not bad! 232% is negligible. I am sure people who share this opinion wouldn't mind having their salary reduced by 2.32x.

Just for one day, you should try not being such a hater. You know, it's possible to be a realist without being an asshole.

[dreamcat4]

i think the lack of vectorization is a valid thing to point out atm with it as-is. however you are then criticising a moving target and simultaneously characterising it as-if it is already reached its steady state end of the road / end game / can never get better. which was in no way my impression here reading about it.

i would suggest that comparing performance to js... well it is probably helpful to know. but no contest in terms of being a fair fight right?

then does exist a few other types of portable cross platform options: such as go or java may be interesting. not just only the c/c++/rust at that far end extreme. to give a feeling.

and bear in mind: a lot of web stuff (cloud technologies) are being written in go these days. so wasm and all that being in this sphere, it is rather appropriate matter to consider given web based client and server components with shared chunks of code. as are the mobile apps and so on (for example ios swift, kotlin, and flutter)