6 ms·

Odd. When I read the article, I thought "creating cancer" is a pretty good description of the idea that one embeds a whole f*ing JavaScript runtime and accept a

Odd. When I read the article, I thought "creating cancer" is a pretty good description of the idea that one embeds a whole f*ing JavaScript runtime and accept a 10x performance decrease on runtime just so that you can avoid copying one .so file around.

masklinn 4y ago
> 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.
- deleted 4y ago
  [deleted]
- nuc1e0n 4y ago
  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.
  - masklinn 4y ago
    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.
    - nuc1e0n 4y ago
      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?