3 ms·

I'm not sure I understand the use case of the author. He mentions languages (Rust, C++ etc) that can be natively compiled to (almost) any platform, so what's th

I'm not sure I understand the use case of the author. He mentions languages (Rust, C++ etc) that can be natively compiled to (almost) any platform, so what's the point of running them in web assembly ? Like Java write once run everywhere ?

rmoriz 6y ago
My speculation: WASM will be used as default for edge computing and further cloud based containers. Cloud vendors will develop custom silicon optimized for WASM that won't be available for general public, maybe on ARM or RISC-V.
- MaxBarraclough 6y ago
  > custom silicon optimized for WASM I doubt it. Like Java, WASM is intended to be used with an optimising JIT compiler. It doesn't make sense to try to implement Java or WASM directly in hardware. ARM used to offer Jazelle, which could run Java bytecode directly on the CPU. It's now long dead. It makes more sense to use a sophisticated optimising JIT to produce efficient machine-code, than to make hardware to directly run an unoptimised IR.
  - rmoriz 6y ago
    I'm sure it is already in the works. WASM is the key to be independent of the ISA and allows to switch to custom silicon without having the customers to know. That's how cloud vendors will drive the future in the race to get independent from x86 and ARM (very likely that a future owner of ARM will limit the licensing business). So even if there is no performance gain possible due to the reasons you have pointed out, it's probably the abstraction layer of the future for pretty much everything.
    - MaxBarraclough 6y ago
      > I'm sure it is already in the works. Why? As I just said, this kind of hardware approach doesn't make technical sense. > WASM is the key to be independent of the ISA and allows to switch to custom silicon without having the customers to know. We already have ISA-independence with JavaScript, Java bytecode, .Net, Python, and other high-level languages. Again, WASM isn't intended for direct execution on hardware, it's intended to be fed to an optimising JIT compiler. Direct execution on hardware isn't how you get good performance out of an IR like this. > That's how cloud vendors will drive the future in the race to get independent from x86 and ARM I don't think cloud vendors care all that much who they buy their CPUs from. AWS offer instances on Intel, AMD, and ARM CPUs. If they really want ISA-freedom, their best bet is RISC-V. > even if there is no performance gain possible due to the reasons you have pointed out, it's probably the abstraction layer of the future for pretty much everything. There will never be a single abstraction layer for everything. Compiler engineering doesn't work that way.
  - hinkley 6y ago
    Azul systems made custom hardware for around a decade, tuned for running Java and highly parallel (IIRC they had 256 core systems when Intel was selling 4 core systems). Also had hardware accelerated GC, so people with large heap problems would talk to them. With the rising ubiquity of Intel VT extensions, they figured out how to put the VM into JVM, particularly for accelerated GC, and it looks like they got out of the hardware business. All I see on their product page is runtimes. And now that Oracle wants to charge people for their JVM, I suspect they have more customers now.
Deukhoofd 6y ago
The author seems to mostly care about the native performance in a sandboxed environment.
tym0 6y ago
These last few days I've been tickering with wasm3 and Rust as way to run Rust on ESP32. The xtensa architecture has still not been merged into upstream llvm so it's quite hard to run Rust on these MCU.
- aerismio 6y ago
  Hard-realtime performance is very important for Microcontrollers. Do you think WASM can do hard-realtime?
  - tym0 6y ago
    I think WASM can do hard-realtime but that's not really the goal of wasm3, they advertise 14x slow-down compared to "native". However I think a lot of usages of MCU are not actually "hard-realtime", my connected light bulb for example uses the ESP32, I don't think you would get a noticeable difference in perf by using wasm3 but you probably get a lot of benefits, OTA for example, running an interpreter.
    - maxgraey 6y ago
      Did you see this repo? https://github.com/vshymanskyy/Wasm3_RGB_Lamp https://github.com/vshymanskyy/Wasm3_RGB_Lamp It's realtime wasm3 led strip animation on 16 MHz Cortex-M0
    - hinkley 6y ago
      Hard real-time is fundamentally about never agreeing to start something you can’t finish. It has nothing at all to do with throughput. What matters is whether there are any unbounded or loosely bounded operations in your call tree. Like memory management bookkeeping. I worked with Aicas’ hard real-time VM for three years, although we were not using those features. Among other things, they had to implement their own amortizing garbage collector to do it. You’d need something similar for Rust to handle object life cycles. It’s also common to divide memory into regions so that different classes of traffic can’t exhaust system memory.

rmoriz 6y ago

My speculation: WASM will be used as default for edge computing and further cloud based containers. Cloud vendors will develop custom silicon optimized for WASM that won't be available for general public, maybe on ARM or RISC-V.

MaxBarraclough 6y ago
> custom silicon optimized for WASM I doubt it. Like Java, WASM is intended to be used with an optimising JIT compiler. It doesn't make sense to try to implement Java or WASM directly in hardware. ARM used to offer Jazelle, which could run Java bytecode directly on the CPU. It's now long dead. It makes more sense to use a sophisticated optimising JIT to produce efficient machine-code, than to make hardware to directly run an unoptimised IR.
- rmoriz 6y ago
  I'm sure it is already in the works. WASM is the key to be independent of the ISA and allows to switch to custom silicon without having the customers to know. That's how cloud vendors will drive the future in the race to get independent from x86 and ARM (very likely that a future owner of ARM will limit the licensing business). So even if there is no performance gain possible due to the reasons you have pointed out, it's probably the abstraction layer of the future for pretty much everything.
  - MaxBarraclough 6y ago
    > I'm sure it is already in the works. Why? As I just said, this kind of hardware approach doesn't make technical sense. > WASM is the key to be independent of the ISA and allows to switch to custom silicon without having the customers to know. We already have ISA-independence with JavaScript, Java bytecode, .Net, Python, and other high-level languages. Again, WASM isn't intended for direct execution on hardware, it's intended to be fed to an optimising JIT compiler. Direct execution on hardware isn't how you get good performance out of an IR like this. > That's how cloud vendors will drive the future in the race to get independent from x86 and ARM I don't think cloud vendors care all that much who they buy their CPUs from. AWS offer instances on Intel, AMD, and ARM CPUs. If they really want ISA-freedom, their best bet is RISC-V. > even if there is no performance gain possible due to the reasons you have pointed out, it's probably the abstraction layer of the future for pretty much everything. There will never be a single abstraction layer for everything. Compiler engineering doesn't work that way.
- hinkley 6y ago
  Azul systems made custom hardware for around a decade, tuned for running Java and highly parallel (IIRC they had 256 core systems when Intel was selling 4 core systems). Also had hardware accelerated GC, so people with large heap problems would talk to them. With the rising ubiquity of Intel VT extensions, they figured out how to put the VM into JVM, particularly for accelerated GC, and it looks like they got out of the hardware business. All I see on their product page is runtimes. And now that Oracle wants to charge people for their JVM, I suspect they have more customers now.

Deukhoofd 6y ago

The author seems to mostly care about the native performance in a sandboxed environment.

tym0 6y ago

These last few days I've been tickering with wasm3 and Rust as way to run Rust on ESP32. The xtensa architecture has still not been merged into upstream llvm so it's quite hard to run Rust on these MCU.

aerismio 6y ago
Hard-realtime performance is very important for Microcontrollers. Do you think WASM can do hard-realtime?
- tym0 6y ago
  I think WASM can do hard-realtime but that's not really the goal of wasm3, they advertise 14x slow-down compared to "native". However I think a lot of usages of MCU are not actually "hard-realtime", my connected light bulb for example uses the ESP32, I don't think you would get a noticeable difference in perf by using wasm3 but you probably get a lot of benefits, OTA for example, running an interpreter.
  - maxgraey 6y ago
    Did you see this repo? https://github.com/vshymanskyy/Wasm3_RGB_Lamp https://github.com/vshymanskyy/Wasm3_RGB_Lamp It's realtime wasm3 led strip animation on 16 MHz Cortex-M0
  - hinkley 6y ago
    Hard real-time is fundamentally about never agreeing to start something you can’t finish. It has nothing at all to do with throughput. What matters is whether there are any unbounded or loosely bounded operations in your call tree. Like memory management bookkeeping. I worked with Aicas’ hard real-time VM for three years, although we were not using those features. Among other things, they had to implement their own amortizing garbage collector to do it. You’d need something similar for Rust to handle object life cycles. It’s also common to divide memory into regions so that different classes of traffic can’t exhaust system memory.