Hacker News Reader

Comment by nagisa | Hacker News Reader

The answer lies in the reason why you would use an embedded scripting language/environment at all, over just loading native code plugins – sandboxing, fault isolation and such.

RISC-V seems to be used here more as a bytecode format of sorts, and at least compared to x86_64 it should be much easier to implement (first of all because all of the opcodes have the same size.)

View on HN

Using a sandboxed bytecode VM has merit, but I would naively expect wasm to be far better at it since RISC-V was designed for hardware and wasm was designed for exactly this usecase (sandboxed code running in another application with good performance and isolation).

(Although... I do see value in having a second option. I guess it might be worth seeing if it can actually be better, even though it's not the thing I would have written)

I mean sure, but virtualization is a very robust (and much lower overhead) technology that is readily available (and supported by the processor). If you just want isolation, why wouldn't you use that? You still have to ship a compiled binary after all.

If you just want to run some CPU bound code as fast as possible, virtualisation has low overhead.

But if you are doing a lot of communication between the script and the host system, I'm not sure virtualisation does so well?

No, as the author of TinyKVM, the overheads of entering and leaving KVM is not the same order of magnitude as SFI. TinyKVM requires 2-3 microseconds to enter and leave, which is the lowest I ever managed to get while it still being robust and dependable sandbox. For some, that might seem really low, but keep in mind that libriscv which is the backbone of RVScript has 3 nanoseconds overhead.

Thanks!

Reply on news.ycombinator.com