5 ms·

If I understand correctly, the idea here is to provide safe scripting by running a RISC V emulator. The "scripts" would be written in C/C++ compiled to RISC V.

• fwsgonzo 2y ago
  This whole comment sounds dismissive towards both me and RISC-V as an architecture people actually run their computers on. I have a lot of blog posts that you can read to get up to speed. Or maybe you already made up your mind.
  • JonChesterfield 2y ago
    Risc-v is a hardware ISA optimised for education. Wasm is a sandboxed IR optimised for compilers. It would be phenomenally unlikely for risc-v to be better than wasm in the exact domain wasm was built to excel at.
    • thefaux 2y ago
      Both are targets for a general purpose programming language. As OP commented below, wasm is a stack machine while riscv is a register machine. It would surprise me if there is any wasm program for which there is not a semantically equivalent and faster riscv implementation.
      • JonChesterfield 2y ago
        Wasm has locals and block arguments, it's no more a stack machine than risc-v is a stack machine.
  • ceronman 2y ago
    In no way I intended to be dismissive of you work or the RISC-V architecture. I apologize if my words could be interpreted in that way. I actually think that RISCV is a really cool architecture, mostly because it is open. I would love to see it getting more traction in the hardware world. I also think that your work on libriscv is impressive! My criticism was at the idea of using a RISC-V emulator as a scripting platform. And I'm not saying that it doesn't work, only that I personally think that Web assembly seems a better option for that particular use case.
    • fwsgonzo 2y ago
      I've been at it for a few years now and my experience with game engine scripting is that the functions are small, and that it's helpful or pleasant to have the ability to make many calls back into the game engine to ask for things, even simple things. My measurements have shown time and again that libriscv spends 3ns entering and leaving the emulator dispatch, and 2ns to execute a system call or even a more complex host function scheme (using custom instructions). So now it's a race. For example, wasmtime needs 48ns just to enter and leave, and 24ns to make a call into the host. That's around 100-150 instructions libriscv can execute before wasmtime has even overcome the fixed call latencies. And then add 50 each time we make a call back into the engine. Now combine this with my ~200 host functions in my game, and I don't know how many in-game events. Which function would wasmtime be faster at? I don't know, probably not a single one. And that's really it. There's no fibonacci computations in game engine scripting. It's just logic. As far as using complex run-times for scripting: I've already been doing this dance for years now. For example, TinyKVM is a native performance KVM userspace emulator that I among other things ran v8 inside. You can find my research paper about it. So it's not like I couldn't throw v8 in there and slideware some JS solution. But, I really do prefer writing C++. Also related is attack surface. libriscv is 10k LOC. wasmtime is what, 350k LOC? Here is a random function I benchmarked: https://fwsgonzo.medium.com/a-sandboxed-rainbow-function-b429b91850a5 https://fwsgonzo.medium.com/a-sandboxed-rainbow-function-b42... wasmtime spent 107ns and libriscv 57ns. Those kinds of functions is your average script function. And, even if we were exactly matching in latency, I would still call that a win! EDIT: To add, you did make a good point about tooling, components etc.
• neonsunset 2y ago
  It's a classic fallacy of thinking "interpreter would be fast enough". Except here it's worse by not even getting the productivity advantage of automatic memory management! No, use something actually good for gamescript, like C#, which is industry proven and has no issues interpreted languages suffer from. I'm always baffled this even has to be said, yet enthusiast circles keep sabotaging themselves in assuming they can do better with techniques known to do worse.
• bitwize 2y ago
  Or QuakeC. That's pretty much what QuakeC was like.
  • Narishma 2y ago
    I don't think so. QuakeC was its own language. This is more like Quake 3 which used a general purpose VM that you could compile regular C to.
  • bjconlan 2y ago
    I'm so glad this was mentioned every time I see performance related metrics I really wish there was more documentation on how quakec/quake vm worked. Mind you https://fabiensanglard.net/quake3/qvm.php https://fabiensanglard.net/quake3/qvm.php is very good on the technical breakdown which is far more valuable.
• senkora 2y ago
  > There are probably more languages compiled to Wasm than to RISC V. Especially for higher level languages, which is attractive for scripting. To expand on this, this is especially useful for modding. The original developers should probably standardize on a single scripting language for practical reasons, but individual modders or groups or modders may benefit from being able to choose their scripting language independent of the original developers'.
• pcwalton 2y ago
  I agree; wasm would be a better choice, as it's specifically designed for this use case. RISC-V is designed for hardware implementation, not to be an IR, which means that things are more verbose than they need to be. For example, accessing an arbitrary 64-bit address requires 6 instructions [1] in RISC-V, whereas in Wasm you can just do it. Even more important than ISA differences, though, is that with Wasm you get WASI, which saves you a whole lot of time creating a sandboxed system interface. [1]: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/388#issuecomment-1737115297 https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/38...
  • snvzz 2y ago
    While legacy ISAs can easily emulate RISC-V, it is actually native on RISC-V. Considering RISC-V is inevitable, this will prove a good decision.