6 ms·

To my knowledge (correct me if I'm wrong please), the performance issues from WASM only exist in the context of moving things back into the DOM. I was always of

by y4mi 5y ago

To my knowledge (correct me if I'm wrong please), the performance issues from WASM only exist in the context of moving things back into the DOM. I was always of the understanding that WASM itself is super performant and if it's possible to run a WASM application without going through the DOM you'd get native performance, making it a valid choice for things like gaming. Most devs would obviously still use unreal engine etc, but these engines will be able to give you improved performance of your games by utilizing WASM

kllrnohj 5y ago
WASM gets you faster performance than JavaScript, sure, but it's not native, either. Sandboxing & byte code aren't free to have. See the extremely long history of existing byte code VMs here - WASM isn't really doing anything new.
- manmal 5y ago
  Modern hypervisors have astonishing performance, and I don’t see why Chrome and Safari wouldn’t manage to eventually provide a similarly efficient implementation.
  - kllrnohj 5y ago
    Modern hypervisors don't run bytecode and are using the CPU to do security enforcement, not software emulating it like WASM is forced to do (since it's not using a hardware protection domain, aka a process)
    - nullifidian 5y ago
      WASM is more secure than a hypervisor, since it prevents code injection.
      - eyberg 5y ago
        It is trivial to modify function pointers, implemented as indirect calls and "read-only" data in wasm.
        nullifidian 5y ago
        Yes, WASM in combination with an unsafe language is less secure than memory safe languages, but more secure than a hypervisor. You can also use WASM with a memory safe language.
        eyberg 5y ago
        It doesn't matter if it's rust or not. You can still modify read only data and still redirect indirect calls. You can still modify the stack and the heap. Rust changes nothing. Also, not sure where the comparison to a hypervisor is coming into play. As @kllrnohj mentioned hypervisors are relying on actual hardware.
        nullifidian 5y ago
        I'm not a rust expert, but I thought rust without unsafes should prevent such things at the compile time. C# and Java will be compiled into WASM differently, I believe no less securely than JVM or .NET. Having information leaks is still better than arbitrary code execution.
        pjmlp 5y ago
        No safe language in the world prevents anything if the attacker can change the binary contents, it is no longer the code produced by the compiler. That is why we have signed binary execution to start with, WASM doesn't support any of this.
        kllrnohj 5y ago
        WASM is less secure than a regular process boundary, and far less secure than a hypervisor. I'm not sure where you're getting this from? Things like spectre mitigations in CPUs are not doing anything for the likes of WASM, after all, they only target process & ring boundaries. It's why you have to enable COOP and COEP to use thread with WASM - because the security for WASM's threads comes from the CPU enforcing process boundaries, not from WASM's sandbox.
    - paavohtl 5y ago
      WASM was explicitly designed to be easy to into native code. No production-ready WASM runtime is interpreting bytecode in hot code paths.
      - kllrnohj 5y ago
        Easy to convert to native code is very different from easy to convert to optimal native code. Just like WASM having performance as a design goal both doesn't mean they achieved it nor does it mean that it won when a compromise had to be made against other design goals like portability or security. In fact I'm quite certain that whenever portability or security ran up against performance in WASM's design, that performance always lost. Those other two goals were definitely a higher priority for WASM's designers. Stable, portable byte codes are always inherently lossy. Information that could be (and often is) useful to optimizers is lost in that conversion. Then the conversion from byte code to running code also is on the hot path - it's on the hot path of starting execution. This is the same problem existing byte code solutions face, like CLR & JVM. WASM didn't manage to magic a solution where nobody else had. It's the same thing that's been done to death, just with "web" slapped on the front of it & bundled in a browser. That part of "being in a browser" makes it interesting for web devs, sure, but in the broader context of "all of computing" it's... just not? It's what we already have had (and been using!) for decades.
        Findecanor 5y ago
        For some server applications using WASM the biggest performance benefit is not really how fast it is running but how fast it is to start a new WASM instance compared to launching a new OS process. However, I think it would be possible to make systems in which similar instances, because they are written in a type-safe, memory-safe language in the first place, could bypass WASM and both start up fast and run fast optimised code. I have done some research on portable bytecodes, and have some novel ideas for getting more performance, but I agree that the inherent problem remains. One thing that help make optimised C/C++ fast is that optimisers assume that undefined behaviour doesn't get triggered. But in a system for portable code, you can't just assume - you'd have to prove that it can not exist to be able to do the same optimisations, and that is far from straightforward. And when it triggers, it has to work the same say, or it won't be portable (bug-compatible) between hardware.
  - deleted 5y ago
    [deleted]
elevader 5y ago
AFAIK you don't really get native performance, although it's hard to find good data on this (https://nickb.dev/blog/wasm-and-native-node-module-performance-comparison https://nickb.dev/blog/wasm-and-native-node-module-performan... was one I could find on the fly). WASM is still virtual machine based and not compiled to a native executable so this is to be expected I guess, it's supposed to be faster than JS and it achieves that goal. Maybe it can be an alternative to Unity, which would be good enough for a lot of games, but I don't know how that compares.
- dathinab 5y ago
  > not compiled to a native executable except it is, WASM is designed to be AOT compiled to native code. Sure there is a bit of difference, WASM needs additional bounds checks and WASM also doesn't have all the info a more high level compiler has. Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting.
  - elevader 5y ago
    > except it is, WASM is designed to be AOT compiled to native code. Interesting, I didn't know that. How does WASM handle different architectures? Do you build different binaries for x86/arm? Or does it do it the Apple way with the giant bundle that contains all binaries? > Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting. Agreed, that was badly worded. Like you said, one could compare a module written in Unity and compiled to whatever Unity compiles to/is implemented in these days with a module in WASM. Edit: Or does the AOT mean that the format that is shipped is some non-native format but the client compiles everything before the first run?
    - billti 5y ago
      > How does WASM handle different architectures? The same way JavaScript or C#/Java do. It's a bytecode format (typically the first stage in today's JavaScript engines is to turn into a bytecode), which the different engines then JIT for the OS and architecture they are running on. For more details on a couple different engine implementations, you may find the below of interest. - https://v8.dev/docs/wasm-compilation-pipeline https://v8.dev/docs/wasm-compilation-pipeline - https://hacks.mozilla.org/2020/10/a-new-backend-for-cranelift-part-1-instruction-selection/ https://hacks.mozilla.org/2020/10/a-new-backend-for-cranelif...

by y4mi 5y ago

kllrnohj 5y ago

WASM gets you faster performance than JavaScript, sure, but it's not native, either. Sandboxing & byte code aren't free to have. See the extremely long history of existing byte code VMs here - WASM isn't really doing anything new.

manmal 5y ago
Modern hypervisors have astonishing performance, and I don’t see why Chrome and Safari wouldn’t manage to eventually provide a similarly efficient implementation.
- kllrnohj 5y ago
  Modern hypervisors don't run bytecode and are using the CPU to do security enforcement, not software emulating it like WASM is forced to do (since it's not using a hardware protection domain, aka a process)
  - nullifidian 5y ago
    WASM is more secure than a hypervisor, since it prevents code injection.
    - eyberg 5y ago
      It is trivial to modify function pointers, implemented as indirect calls and "read-only" data in wasm.
      - nullifidian 5y ago
        Yes, WASM in combination with an unsafe language is less secure than memory safe languages, but more secure than a hypervisor. You can also use WASM with a memory safe language.
        eyberg 5y ago
        It doesn't matter if it's rust or not. You can still modify read only data and still redirect indirect calls. You can still modify the stack and the heap. Rust changes nothing. Also, not sure where the comparison to a hypervisor is coming into play. As @kllrnohj mentioned hypervisors are relying on actual hardware.
        nullifidian 5y ago
        I'm not a rust expert, but I thought rust without unsafes should prevent such things at the compile time. C# and Java will be compiled into WASM differently, I believe no less securely than JVM or .NET. Having information leaks is still better than arbitrary code execution.
        pjmlp 5y ago
        No safe language in the world prevents anything if the attacker can change the binary contents, it is no longer the code produced by the compiler. That is why we have signed binary execution to start with, WASM doesn't support any of this.
        kllrnohj 5y ago
        WASM is less secure than a regular process boundary, and far less secure than a hypervisor. I'm not sure where you're getting this from? Things like spectre mitigations in CPUs are not doing anything for the likes of WASM, after all, they only target process & ring boundaries. It's why you have to enable COOP and COEP to use thread with WASM - because the security for WASM's threads comes from the CPU enforcing process boundaries, not from WASM's sandbox.
  - paavohtl 5y ago
    WASM was explicitly designed to be easy to into native code. No production-ready WASM runtime is interpreting bytecode in hot code paths.
    - kllrnohj 5y ago
      Easy to convert to native code is very different from easy to convert to optimal native code. Just like WASM having performance as a design goal both doesn't mean they achieved it nor does it mean that it won when a compromise had to be made against other design goals like portability or security. In fact I'm quite certain that whenever portability or security ran up against performance in WASM's design, that performance always lost. Those other two goals were definitely a higher priority for WASM's designers. Stable, portable byte codes are always inherently lossy. Information that could be (and often is) useful to optimizers is lost in that conversion. Then the conversion from byte code to running code also is on the hot path - it's on the hot path of starting execution. This is the same problem existing byte code solutions face, like CLR & JVM. WASM didn't manage to magic a solution where nobody else had. It's the same thing that's been done to death, just with "web" slapped on the front of it & bundled in a browser. That part of "being in a browser" makes it interesting for web devs, sure, but in the broader context of "all of computing" it's... just not? It's what we already have had (and been using!) for decades.
      - Findecanor 5y ago
        For some server applications using WASM the biggest performance benefit is not really how fast it is running but how fast it is to start a new WASM instance compared to launching a new OS process. However, I think it would be possible to make systems in which similar instances, because they are written in a type-safe, memory-safe language in the first place, could bypass WASM and both start up fast and run fast optimised code. I have done some research on portable bytecodes, and have some novel ideas for getting more performance, but I agree that the inherent problem remains. One thing that help make optimised C/C++ fast is that optimisers assume that undefined behaviour doesn't get triggered. But in a system for portable code, you can't just assume - you'd have to prove that it can not exist to be able to do the same optimisations, and that is far from straightforward. And when it triggers, it has to work the same say, or it won't be portable (bug-compatible) between hardware.
- deleted 5y ago
  [deleted]

elevader 5y ago

AFAIK you don't really get native performance, although it's hard to find good data on this (https://nickb.dev/blog/wasm-and-native-node-module-performance-comparison https://nickb.dev/blog/wasm-and-native-node-module-performan... was one I could find on the fly). WASM is still virtual machine based and not compiled to a native executable so this is to be expected I guess, it's supposed to be faster than JS and it achieves that goal. Maybe it can be an alternative to Unity, which would be good enough for a lot of games, but I don't know how that compares.

dathinab 5y ago
> not compiled to a native executable except it is, WASM is designed to be AOT compiled to native code. Sure there is a bit of difference, WASM needs additional bounds checks and WASM also doesn't have all the info a more high level compiler has. Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting.
- elevader 5y ago
  > except it is, WASM is designed to be AOT compiled to native code. Interesting, I didn't know that. How does WASM handle different architectures? Do you build different binaries for x86/arm? Or does it do it the Apple way with the giant bundle that contains all binaries? > Now Unity is so much more then just a tool to make cross platform easier. So comparing it to WASM is kinda pointless IMHO. Though it probably is a grate choice for any extension mechanism, like mods or even in game scripting. Agreed, that was badly worded. Like you said, one could compare a module written in Unity and compiled to whatever Unity compiles to/is implemented in these days with a module in WASM. Edit: Or does the AOT mean that the format that is shipped is some non-native format but the client compiles everything before the first run?
  - billti 5y ago
    > How does WASM handle different architectures? The same way JavaScript or C#/Java do. It's a bytecode format (typically the first stage in today's JavaScript engines is to turn into a bytecode), which the different engines then JIT for the OS and architecture they are running on. For more details on a couple different engine implementations, you may find the below of interest. - https://v8.dev/docs/wasm-compilation-pipeline https://v8.dev/docs/wasm-compilation-pipeline - https://hacks.mozilla.org/2020/10/a-new-backend-for-cranelift-part-1-instruction-selection/ https://hacks.mozilla.org/2020/10/a-new-backend-for-cranelif...