Hacker News new | ask | show | jobs
by garganzol 1120 days ago
Ok, considering that it comes from VMware, I think they aim to create some kind of a multi-architectural execution environment that can host apps in a hardware-independent way on multiple clustered nodes.

I applaud this development but at the same time any kind of run-time code translation imposes performance penalties. WASM is not exception. It would be enlightening to hear the authors' stance on this topic. CPU utilization factor is a big thing for hosting companies, so they will be hesitant to use something like this in production.
2 comments
ridruejo 1120 days ago
VMware is a big company and there's a lot of interesting ways Wasm is being used internally. In our particular case, the aim of our group is not the one you outline. It is a bit higher level: how can we bring the most developers possible into the Wasm ecosystem? PHP + mod_wasm support is a way of getting the "LAMP stack" crowd an easy on-ramp. There are other ecosystems like Rust that already have had great Wasm support since early on and that's not necessary. There is work going in the direction that you point out, and there was a WasmEdge article a few hours ago on how to run on ARM, etc. https://news.ycombinator.com/item?id=36110253
link
giancarlostoro 1120 days ago
So a GraalVM competitor but on WASM.

I do want to see the WASM ecosystem grow and thrive, but it will take some time, although what I have seen so far is amazing. I am most excited for WASI. Havent checked up on it in a moment but its basically the WebAssembly version of nodejs but as a spec anyone implementing a WASM runtime can support, so there will be various options to run your code ultimately.

link
garganzol 1120 days ago
Yes, I agree on WASM versatility, but: when I use my Mac M1 (with ARM64 processor) and try to run a x64 based executable, there is a small but noticeable lag on the app's start. It is caused by the dynamic instruction translation, essentially by JITting x64 code to ARM64 instruction set on the fly.

While the lag is small, it is unpleasant enough to make my work less comfortable when compared to the native ARM64 images.

The story repeats itself with Windows 11 ARM64 - it can run x86 and x64 images but there is a price to pay - they are not as snappy as native ARM64 images due to the dynamic translation costs.

Having a WASM on board poses the same kind of dilemma which directly impacts hosting bills.

link
gzurl 1120 days ago
Actually, that is one of the Wasm key features: being a platform-independent binary not tied to any specific HW architecture.

Translating x86_64 code to arm64 requires more CPU cycles than JITting Wasm into arm64 or x86_64.

Buy even more: in the use case covered in this article, the PHP interpreter won't change so it can be AoT compiled upon deployment to the target architecture. No JIT compilation needed :-)

link