5 ms·

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

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.

sspiff 3y ago
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?
azakai 3y ago
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 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.)
- fwsgonzo 3y ago
  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?
  - azakai 3y ago
    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.

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.

sspiff 3y ago

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?

azakai 3y ago

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 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.)

fwsgonzo 3y ago
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?
- azakai 3y ago
  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.