For anyone that is interested in understanding Web Assembly at the systems level, I've put together a document (wasm.pdf, attached below) that details how the entire end-to-end process is implemented under the hood. None of this is necessary for developing WASM modules, but hopefully anyone doing serious work in the WASM space will find it interesting and useful.
-
Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:
- Tag FS2020 specific questions with the MSFS2020 tag.
- Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
- Questions about aircraft design can be posted in the Aircraft design forum
- Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
- Questions about terrain design can be posted in the FS2020 terrain design forum.
- Questions about SimConnect can be posted in the SimConnect forum.
Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.
By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.
MSFS20 WASM Deep Dive
- Thread starter geoffda
- Start date
- Messages
- 89
- Country
The document says This would imply that the possibility exists of building add-ons in other languages and that is apparently indeed the case. At least the FlyByWire people seem to be using Rust (!). See for instance this folder . (I have no personal experience of that, and don't know Rust.)
- Messages
- 89
- Country
Do you by the way understand why the process that compiles a .wasm module into a DLL takes so long? I mean the thing that shows up in the DevMode Console window as
The .wasm file in question is a bit under a megabyte, generated from about a thousand lines of fairly trivial C++ code. 26 seconds? Wow. When the compilation from C++ into Wasm by Visual Studio takes about a second. (No wonder the Aerosoft people need to warn that when flying their CRJ, which also uses Wasm, the first loading of the aircraft can take up to ten minutes during which the simulator appears stuck.)
But yeah, many other things in MSFS and its DevMode are mysteriously slow, too. I am sure they will improve over time.
WASM: Compiling module FlyingBrick.wasm
WASM: Compiled module FlyingBrick.wasm in 26 seconds (Init: 0 ms / Compile: 585 ms / Optim: 0 ms / Link Init: 246 ms / Link Generate: 25356 ms / Link LLVM: 61 ms).
The .wasm file in question is a bit under a megabyte, generated from about a thousand lines of fairly trivial C++ code. 26 seconds? Wow. When the compilation from C++ into Wasm by Visual Studio takes about a second. (No wonder the Aerosoft people need to warn that when flying their CRJ, which also uses Wasm, the first loading of the aircraft can take up to ten minutes during which the simulator appears stuck.)
But yeah, many other things in MSFS and its DevMode are mysteriously slow, too. I am sure they will improve over time.
I'm not sure why it is so slow, though I'd hazard a guess that the virtual file system may be the culprit. Probably the starting point for that investigation would be to download the inNative SDK and then build a quick test application (linking the static library) to generate a dll from WASM. Assuming one could figure out the correct inputs to generate an identical dll, doing so would provide a pretty good baseline for how fast the build process should be. Incidentally, inNative is using a custom fork of LLVM and the sources are provided, so it would be possible to build the toolset and do some profiling with it if it turns out to be slow.
I was thinking more about inNative last night; I kind of glossed over it in the document since it was enough for me to understand where the built PE was coming from. That said, there are some interesting questions around the details of the inNative build process. I'm also kind of curious about whether it would be possible to break into the build process inside of FlightSimulator.exe. The first step would be to install the inNative SDK and then dump the static library to examine the symbols. Then assuming the compilation process happens late enough, it might be possible to set some breakpoints (depending on whether the labels are obfuscated). If that could be done, it would be possible to use Visual Studio's built-in profiling tools to do a direct comparison between the build process inside of FlightSimulator.exe and the build process inside of a sample app.
Glad you posted this question. With the PMDG 737-700, the compile time is 20-30 minutes! I'm running an i7 12700k with 32GB of RAM. I'm surprised to see that the CPU is barely working. I expected to see one core getting hammered but that's not the case at all.
I'm not a coder or programmer... I hope someone with skills can dig into it and help figure it out.
An excerpt from this thread is shown below.
WASM Compilation time on user PCs weird behaviors - MSFS DevSupport
Enterprise solution for all your Social Q&A needs.
devsupport.flightsimulator.com
FlyingRaccoon answered • May 30 2022 Regarding WASM compilation, it's done on the user machine to make sure it matches its specs and doesn't use unavailable set of instructions. The good side of this is that it's very optimized for the user machine.