Consider updating NaCl as an alternative to WebAssembly #795
Labels
Comments
|
Some weeks ago I investigated “chromium builds” and I only found nacl stuff in Linux builds. Even macOS amd64 chromium did not have any nacl stuff, and I have seen some commits disabling nacl for macOS. Edit: I also found some arm64 references, but no builds. |
|
Some search about “Saigo” and “Native Client” returned me this: https://chromium.googlesource.com/native_client/nacl-llvm-project-v10/+/refs/heads/saigo-2023-01-02 |
|
For the record, the C++ toolchain that we would be most likely to use for wasm is upstream clang. This might be the lowest maintenance toolchain we could ever get. |
|
+1, if Google somehow makes the NaCl thing slightly more user friendly, I think it's better than wasm for now. Wasm doesn't really provide us any features beyond even more modern C++. For example, in the switch from QVM -> NaCl, if we could have supported C++ on QVMs, we probably would have done that instead of using NaCl. |
|
To be able to upgrade NaCl we need two things:
|
|
I think it is also important to reference this thread on the forum, which says that wasm is 2 times slower than native binaries and author seems to have done their research there. Performance is important as people can only rent cheap VPS to host servers with their own gameplay, and test their own mods. Bots are notably performance hungry, and they were moved from engine to gamelogic thanks to pNaCl near-native performances, I suppose. Keeping up with pNaCl, we would avoid spending developer time (a very scarce resource) on another porting, everything is already there. We would avoid hardly avoidable regressions, too, that can be very annoying. Avoiding compatibility break and sync problems between clients and servers, too. The main incentive to move to WASM was, IIRC, that pNaCl was thought dead. If it is not, then it would probably be a waste of time, except if the move is almost finished, in which case the decision is a bit harder to do, I guess. |
|
About updating nacl, there are some old-but-less-old versions available: We are currently using The latest public |
|
For reference, we use a |
|
I tried to upgrade to the latest release (which was like 6 months newer than the one we're using) one time, but abandoned the attempt because it turned out that toolchain support for C++ exceptions was removed. It's not that hard for us to live without exceptions, but it just didn't seem worthwhile since the benefits were too small. |
|
Getting the PNaCl, old GCC, and Saigo toolchains: Writing some C source test samples: Testing the PNaCl toolchain: Testing the old GCC toolchain: Testing the Saigo toolchain: |
|
Well… The build is from 2015… :-/ This is probably the toolchain from before the pexe was a thing. |
|
The |
|
I managed to get saigo build an This is based on clang 17 and the build looks to be from today: |
|
That saigo clang doesn't complain if I use |
|
while The file can then be found as: |
|
Even with a saigo toolchain from today there is still no |
|
Also I fail to build a pexe with saigo, that would mean building every nexe platform from scratch instead of just translating a single pexe: |
|
Since it's doable to rebuild the nacl_loader, out of curiosity I wonder if it can be rebuilt for armel (and then, Android). |
|
If the PNaCl format no longer exists, that may or may not be bad for us... yes, we would have to compile all the code multiple times, but the translation (PNaCl -> NaCl) step is so slow that the overall build time might not really be worse. I bet it's faster at least for incremental builds. |
|
Sounds like a worthwhile thing to test then |
|
I will probably spend time on updating NaCl only if we find WAMR unusable, see: I consider that the priority on that topic after next release is to investigate WAMR then fallback on updated NaCl if WAMR is proven unusable. |
|
If work is done on "moving", please keep in consideration the need to have a transition period where both are supported, as such a move can trigger hard to find bugs in mods, that only time can reveal. |
|
I assume the way to build for a newer NaCl or for Wasm would require a very different CMake code than our current code with PNaCL, so I think that would even be easier to not modify the existing code but to add code, this means having the two toolchains in CMake may be even easier. For the virtual machine plumbing I have no idea though. At QVM/NaCl time we did a transition where both existed at the same time, and there was a time were the server was running NaCl by default and the client was still running QVM by default while ironing out the last bits. |
|
To change my mind I toyed with Saigo a bit, and I got this: |
|
I now wonder if Saigo SDK exists for Windows. Here are the instructions I use to get the Saigo toolchain: Then I get But in |
|
Does Saigo support setjmp/longjmp at least? |
|
I have no idea about setjmp and Saigo! The instructions above are enough to get a working compiler on Linux, which makes it possible to investigate saigo with PoC or even benchmarks, and test for specific feature support. For a Linux developer everything is available, it's just not really designed to be redistributed. For more information about a possible migration to saigo, it is very easy to build the saigo compiler itself (it's just very hungry on resources): it's just like building clang since it's a clang fork. What is complicated is to build the nacl libc/libc++ and maybe some other tools. A first migration step would be to make it possible to build the saigo compiler but rely on prebuilt saigo libc/libc++. |
|
setjmp/longjmp seem to work with some simple examples. |
20 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Google Native Client, or NaCl, is not as dead as has been previously believed. Although support for NaCl in websites and 3rd-party browser extensions has been removed, it lives on in some form. This bug tracking issue details the development in 2020-2021 of a C++17-capable NaCl compiler toolchain, codenamed "Saigo". CI-related commits show that it is actively tested on numerous platforms, so it is not just a ChromeOS thing.
After poking around a bit in Chromium Code Search, I still haven't been able to determine what NaCl is being used for. Chromium has a lot of "sandboxed" processes, but in general these are not NaCl-based. But as of now the code is being shipped with Google Chrome: inspection of a Windows install shows a
nacl_irt_x86_64.nexeand various NaCl-related strings inchrome.dll. So the chances of it being available for any platform Daemon would want to support seem good. (Contrast this with standalone WebAssembly engines which are more popular for Linux servers and have not been ported to 32-bit architectures.)The text was updated successfully, but these errors were encountered: