pNaCl to Wasmtime?

Talk about anything related to Unvanquished.
Post Reply
rygo6
Posts: 3
Joined: Tue Feb 07, 2023 9:12 am UTC

pNaCl to Wasmtime?

Post by rygo6 »

Hello. I just stumbled on your project searching about the q3vm. I was intrigued to see you're using pNaCl for sandboxed game logic and you're pulling that out in favor of WasmTime. Reason for my intrigue is, for a number of months now I have been on a serious deep dive through all sorts of sandboxed VM scripting solutions that could possibly be used in a gaming context. I actually first started with WasmTime, then switched to another wasm VM, then at one point convinced myself NaCl was maybe the better route to go, and also convinced myself a few other completely different paths were better. Even read a bunch of whitepapers and considered making the edits to sandbox a C compiler myself. I am still not 100% certain of the ideal route for sandboxed game logic. So I was curious to ask, since it seems you have dealt with almost the same exact decision I've been researching. What were your reasons for leaving behind pNaCl and going to WasmTime? Would you be willing to document and share anything for that? Was there any particular technical analysis, or benchmarks? Thank you.

rygo6
Posts: 3
Joined: Tue Feb 07, 2023 9:12 am UTC

Re: pNaCl to Wasmtime?

Post by rygo6 »

Which source were you trying to compile? I haven't tried it yet but the one here looked like it'd build the same as LLVM itself? https://chromium.googlesource.com/nativ ... heads/main

But for my WASM concerns. Probably the first thing which made me have concerns about WASM is that still in 2023 it doesn't live up to the "Near Native Performance" promise.
https://00f.net/2023/01/04/webassembly-benchmark-2023/
The best possible WASM VM is still less than half the speed of native.
https://00f.net/img/posts/wasmbench4/vsnative.png
For the popular ones like wasmtime or wasmer it's even worse.

I've been hoping this would evolve, but I am starting to believe that the culture surrounding wasm isn't really putting performance as a primary objective but are more so putting it as a nice-to-have. Culturally I find WASM is seen as a v2 of Javascript, not a v2 of native code, so there is really only a push to make it better than Nodejs. I think this is partly due to maintainers of big VMs needing to care more about performance in actual implementation. But another big part is disallowing certain opcodes based on philosophical ideology inherited from Javascript that inhibits true assembly-like optimizations. This article goes into some of it a little bit: http://troubles.md/why-do-we-need-the-r ... thm-again/ Unfortunately this has been a long-running controversy in WASM without any end in sight. This effects not just runtime speed, but also compiler speed and complexity as they have to deal with this.

Another issue is that of memory on mobile devices, which again I think is intertwined with the whole mentality of performance being a nice-to-have.
https://github.com/WebAssembly/design/issues/1397
Which is also disappointing as I had always hoped WASM would be what could displace the mobile app store paradigm with something truly efficient in a browser.

None of that is necessarily show stopping though. WASM of course still has tons of uses and could be used for game scripting. It's just that objectively speaking it's a performance downgrade over something like NaCl which was designed from ground up and implemented by a performance-is-a-must-have team. Already there is some concerning things brewing in WASM-land related to this. Like the whole controversy about needing to add a native GC, which wouldn't be necessary if it actually ran comparable to native, just compile the GC to WASM, but since it doesn't a 'Unified Native GC' makes sense. This type of thinking is signifying to me WASM is not really an assembly nor native code replacement but is rather going to become another VM with many of its own idiosyncrasies. Which again is useful, just it's a different purpose than only 'Sandboxed Portable Native Code'.

Which is why I've been left ruminating the thought that maybe I should fork NaCl and start to turn it into what I want. Or maybe apply similiar sandbox methodology from NaCl to an easier to maintain compiler

User avatar
illwieckz
Project Head
Posts: 718
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: pNaCl to Wasmtime?

Post by illwieckz »

Well, the reason why we are looking for replacing NaCl with Wasm is pure pragmatism. We don't have the resources to maintain something like NaCl or Wasm ourselves. It happened that the market basically shifted from NaCl to Wasm, so sticking to NaCl is just making us alone, or so.

The latest distributable NaCl SDK is from 2016, 2017 for what was the non-stable one. Even the tools to download them requires patches to not fail at downloading them today. Those SDK even require Python2 which is deprecated since years and we recently had to port that part of the distributable NaCl SDK ourselves to remove the build dependency on deprecated Python2.

This distributable SDK only provides support for running nexe on 32-bit and 64-bit x86, and 32-bit arm and 32-bit mips. The way we currently run our game on arm64 on Linux is very hacky by running a 64-bit engine with a 32-bit nexe gamecode (with 32-bit NaCl runner), maybe the same hack can be done on Windows arm64 (I don't know), but there is no hope for doing that on arm64 on macOS (so, no native M1 support).

I know there is some NaCl stuff that is still maintained as part of Google Chrome browser. I seen the Linux Chrome/Chromium browser still ships some updated NaCl runner. I looked at them to see if we could borrow newer NaCl stuff from Chrome instead of using the now deprecated old distributable releases. I have seen Google had ported NaCl to arm64… but I also seen that Google removed NaCl support from macOS build of Chrome, so that terminated my hope for native Apple M1 build. So maybe I missed some download, but the only recent builds of recent NaCl runner I found in Chrome/Chromium downloads was in x86 builds.

I personally don't mind about using NaCl or Wasm, but we need to have someone else maintaining the stack we use. I sometime tell people to better not fork game engines as maintaining a game engine quickly turns into a full time job, and I know it because we actually maintain our own game engine. The same would happen for a virtual machine and a compiler, so I'm afraid maintaining NaCl would just adds us yet another fulltime job, something we cannot sustain.

If NaCl gets new interest from other parties, gets updated and maintained and ported to newer architectures, we may continue to use NaCl as porting to a newer version of NaCl would be a smaller effort than porting from NaCl to Wasm, but we don't have the resources to maintain NaCl ourselves…

Right now we are already facing some limitations with NaCl being aged, if I'm right we are currently stuck on some old version of our GUI library (RmlUi) because newer version requires a newer C++ standard that is not implemented in the distributable NaCl SDK we use. This issue is very ironic because we switched from Q3VM to NaCl to not be held back by a virtual machine technology that only supported its own very old compiler and very old C standard.

If I'm right slipher said once that on some topics the design of NaCl was superior to Wasm one.

It's even possible that NaCl would not only be faster but also that the sandbox model is better…

But in the end, it happens that Wasm won, very likely because of all the web traction out there.

What we would like to see from NaCl, Wasm or any competitor :

  • Compiler supporting recent C++
  • Multithreading
  • Recent architectures (like arm64 on Linux and macOS)

A plus would be to only have a single binary for all the architectures, or at least, only one per bitness. Right now we have to link and distribute amd64, i386 and armhf nexe because we never found resources to implement pexe translation in game (if it's doable to begin with).

Another plus would be to be able to produce executables from any platform. With the NaCl SDK we currently use we can only produce armhf nexe from amd64 host (maybe it also works from i686 host), so one cannot build an arm NaCl game from an arm machine.

Another interesting solution I recently seen may be Blink (not the web engine). It's a stripped down emulator that just runs amd64 static binaries everywhere. With blink, one may just have to produce one static linux amd64 build for every platform. But this is clearly aimed for portability, not for “Near Native Performance”.

This comment is licensed under cc ​​by 4 and antecedent.

rygo6
Posts: 3
Joined: Tue Feb 07, 2023 9:12 am UTC

Re: pNaCl to Wasmtime?

Post by rygo6 »

Heh, yes, I've wandered quite far in this rabbit hole :) https://twitter.com/_rygo6/status/1622515401354801152

That all makes sense. I guess ya the only plausible route if you wanted to support multi-language sandboxing on multiple platforms is WASM and just hope it improves and proposals can be pushed through :\

User avatar
illwieckz
Project Head
Posts: 718
Joined: Sat Aug 11, 2012 7:22 pm UTC
Location: France
Contact:

Re: pNaCl to Wasmtime?

Post by illwieckz »

and with the information about pNaCl being still maintained,

Well, we still don't know how to build it, neither we don't know how to find newer builds. So maintained or not, the result is like not maintained.

I've looked at some Google repositories, like this one: https://chromium.googlesource.com/nativ ... ive_client

Last commit is from 3 days ago, so it looks maintained. Here are some list of architectures: https://chromium.googlesource.com/nativ ... time/arch/

It listes arm, mips, x86 with 2 subarches: x86_32 and x86_64, but I don't see any arm64 subarch. It is code used by the nacl_loader binary (sel_ldr), so this is something we need to build or get built on the platform and systems we want to run Unvanquished. Something interesting is that the SConstruct file has explicit code to build things on Android, so that would enable one thing we cannot currently. But outside of that potential Android build, I don't see any interest for newer NaCl compared to what we have, so that makes no difference or almost no difference for us if that's maintained or not.

I remember having seen arm64 stuff in NaCl, but that was probably in some google chrome repositories. Things are hard to track.

This comment is licensed under cc ​​by 4 and antecedent.

Post Reply