> I thought "creating cancer" is a pretty good description of the idea that one embeds a whole f*ing JavaScript runtime
wasm is not a javascript runtime.
> and accept a 10x performance decrease on runtime
Unless SIMD is involved (which is indeed a major issue around warm), the overhead of compiled wasm is generally observed below 50%, often closer to 15.
Obviously if you're using a wasm interpreter all bets are off.
It might involve a performance penalty today, but in the years to come vendors will be investing in making it fast. And Wasm has a much smaller surface area to optimise than JavaScript does.
The overhead I’m talking about is compared to native code, not to javascript. I’m not sure why you’re bringing up javascript, it’s nowhere in the discussion except in ggp’s misconceptions.
That's why I mentioned js. There's nothing in principal to stop wasm being implemented in hardware. Then it would be native code. Maybe this can be done easily with an FPGA?
wasm is not a javascript runtime.
> and accept a 10x performance decrease on runtime
Unless SIMD is involved (which is indeed a major issue around warm), the overhead of compiled wasm is generally observed below 50%, often closer to 15.
Obviously if you're using a wasm interpreter all bets are off.