|
|
|
|
|
by ceronman
750 days 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. |
|
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-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.