Hacker News Reader

Comment by azakai | Hacker News Reader

The project explains that the reason is latency.

It is indeed true that most VMs, including JavaScript, WebAssembly, the JVM, etc., have significant latency on the boundary. For example, many wasm VMs will install a signal handler, and that needs to be enabled/disabled on each entry/exit from the VM.

But the latency can be fixed. You can sandbox WebAssembly without a signal handler, in particular (at the cost of a few % throughput overhead for bounds checks). I'm not sure if the author benchmarked that, but it should be very fast.

(As for "why RISC-V" in the project, it looks like that's because it's easy to write an interpreter for, but it could have been any compiler target, it seems.)

View on HN

There's also latencies for arguments into and out from the emulators. I'm not sure the custom signal handling alone can account for that.

I agree that it could as well have been MIPS or ARM.

I think there are a couple of reasons for picking RISC-V over others.

It is the youngest of the lot, meaning it is carrying around the least legacy compatibility stuff while still incorporating a lot of modern design lessons.

Additionally, modern ARM and MIPS are not free and (potentially?) patent encumbered as well.

You could go with some old, free MIPS or ARM, but then how good is performance, and how good is compiler support for these nowadays?

There is no reason I can think of why a Wasm interpreter would have higher overhead for arguments in and out. Maybe I'm missing something?

Wasm was designed to have very fast calls, both internally and externally. That's why the basic types correspond directly to machine types. The goal is to have 0 overhead, except for sandboxing.

Regarding sandboxing, there is the stack overflow check that happens in Wasm on each call. But you can disable that check if you don't want it.

Btw, you can see that Wasm has no extra overhead on calls in a simple way: compile Wasm using wasm2c and inspect the C output. That C is what a Wasm VM would run. Some details:

https://kripken.github.io/blog/wasm/2020/07/27/wasmboxc.html

Note the section there about LTO: The Wasm can even be inlined into the code calling into it, which means there is zero call overhead. (But even without LTO, it's just another C function to call.)

That's definitely a cool project, but I'm only interested in interpreting right now. I am sharing programs with clients, as I wrote in another thread. Not interested in producing or linking native code. I already have a binary translation mode, and I could probably expand it to avoid the interpreter loop to save 2ns, but I just don't have a need. Right now, everything is perfect for my use case.

It's cool that you can inline sandboxed functions like that. I'm curious about how you arbitrarily select and call functions though? A string-lookup kind of thing?

In general you'd have a map between string names and functions, yes. But for static calls you don't need a map lookup of course.

Reply on news.ycombinator.com