3 ms·

> Since WASM is a virtual ISA protected by a virtual machine, we don't need to rely on external hardware and software checks to ensure safety famous last words

> Since WASM is a virtual ISA protected by a virtual machine, we don't need to rely on external hardware and software checks to ensure safety famous last words... > faster than native if you used a static compiled (and safe) language in-kernel i would assume that would be faster still than wasm or am i missing something...?

krageon 7y ago
There is absolutely no way that a more abstracted piece of software is faster than a less abstracted piece of software, unless there is some defect in the latter. Even the hypothetical equal performance is more like a holy grail (though I have had professors swear to me that they have seen it reached in isolated circumstances, so maybe a little less hypothetical than that).
- AnIdiotOnTheNet 7y ago
  I don't think that's a 100% accurate statement. My understanding is that JIT techniques do often allow non-native code to run faster than native code by taking advantage of information during the programs runtime for optimization, in addition to specific hardware features that the compiled binary version may not have taken advantage of for compatibility reasons.
  - Accujack 7y ago
    In other words, it's possible for a non native program to be faster than a native program provided the native program is less optimized for the execution platform. This is not exactly news.
    - Someone 7y ago
      A VM can also optimize for the workload and the configuration of a program in ways that a compiled-once program cannot (profile-guided-optimization can help there) A simple example is log.debug(“foo:” + bar + “(“ + baz + ”)”) A native C++ compiler would have to do the string concatenation and must call log.debug. A VM can (sometimes) detect that “log.debug” is a no-op, and skip computing its argument and calling it, and can even recover when “log.debug” stops being a no-op. It can even do that if the code for log get loaded dynamically at runtime.
      - krageon 7y ago
        What this means in short is exactly what was already said, but in more words and in such a way that it seems like that wasn't what was already said. You've described a native program that wasn't optimised competing against an optimised non-native program. It's already been established that this is a scenario where the latter might be faster.
k__ 7y ago
Seems right to me. I guess they assume the WASM VM to be safe enough, that they can cut on system calls, which other user mode programs can't.

krageon 7y ago

There is absolutely no way that a more abstracted piece of software is faster than a less abstracted piece of software, unless there is some defect in the latter. Even the hypothetical equal performance is more like a holy grail (though I have had professors swear to me that they have seen it reached in isolated circumstances, so maybe a little less hypothetical than that).

AnIdiotOnTheNet 7y ago
I don't think that's a 100% accurate statement. My understanding is that JIT techniques do often allow non-native code to run faster than native code by taking advantage of information during the programs runtime for optimization, in addition to specific hardware features that the compiled binary version may not have taken advantage of for compatibility reasons.
- Accujack 7y ago
  In other words, it's possible for a non native program to be faster than a native program provided the native program is less optimized for the execution platform. This is not exactly news.
  - Someone 7y ago
    A VM can also optimize for the workload and the configuration of a program in ways that a compiled-once program cannot (profile-guided-optimization can help there) A simple example is log.debug(“foo:” + bar + “(“ + baz + ”)”) A native C++ compiler would have to do the string concatenation and must call log.debug. A VM can (sometimes) detect that “log.debug” is a no-op, and skip computing its argument and calling it, and can even recover when “log.debug” stops being a no-op. It can even do that if the code for log get loaded dynamically at runtime.
    - krageon 7y ago
      What this means in short is exactly what was already said, but in more words and in such a way that it seems like that wasn't what was already said. You've described a native program that wasn't optimised competing against an optimised non-native program. It's already been established that this is a scenario where the latter might be faster.

k__ 7y ago

Seems right to me. I guess they assume the WASM VM to be safe enough, that they can cut on system calls, which other user mode programs can't.