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-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.
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.
> 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?
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.
"designed for AOT" means it ships platform independent byte code, which is easy to turn into assembly/machine code before running it.
AOT is a counter part to JIT:
- AOT ahead of time (but still on the system, e.g. just before running)
- JIT just in time (while interpreting code you notice a hot section and turn it into native code)
So what most WASM runtime do is parse the WASM byte code, running certain checks for wellformedness and emit assembly (with necessary bounds checks, etc. to not escape the WASM sandbox).
This doesn't mean you can't interpret it, or interpret + JIT it, it's just that AOT seemed like a better choice then JIT or pure interpretation for WASM, as just interpreting it isn't fast enough compared to JavaScript JIT/or asm.js, to make it worth adding it to the web.
