Robert Gabriel Jakabosky
Robert Gabriel Jakabosky
> Thank you for the updated benchmarks! Yet, `wasmi_v1` still looks a bit slow imo but at least these results are more realistic. My "simple" benchmarks are not high-quality. I...
> > I agree that benchmarking s1vm against a full wasm VM is not fair. Part of the reason I haven't really tried publishing the results, other then just releasing...
> The most recent activities are > > * [Reviving tail-call elimination rust-lang/rfcs#2691](https://github.com/rust-lang/rfcs/issues/2691) > * [Proper tail calls rust-lang/rfcs#1888](https://github.com/rust-lang/rfcs/pull/1888) Thanks for the links. > > The closure design might make...
> * How will the different control flow constructs work like? E.g. `loop` and `if/else`? Currently your POC shows that for basic blocks. Loops and if/else are supported. Only a...
> I re-implemented your interpreter architecture in my research repo under the name [`closure-tree`](https://github.com/Robbepop/interpreter-dispatch-research/blob/main/src/closure_tree.rs). In fact it achieves the best performance of all solutions so far. exploding_head I hope I...
> > I don't think the generated machine code will be that much bigger than a VM with a lot of specialized opcodes. > > That's exactly what I mean....
> > It still seems to pass values in the register's Vec (context.get_reg and context.set_reg). I am a little bit surprised that it was faster. > > https://github.com/Robbepop/interpreter-dispatch-research/blob/fb11eb998fdc299c7d1ffdf0a2ce239013e361f7/src/lib.rs#L61 > >...
> > Not sure if you have seen this document about the wasm3 interpreter: > > https://github.com/wasm3/wasm3/blob/main/docs/Interpreter.md#tightly-chained-operations > > I have seen and read this and understood the basic architecture....
> > For any opcode that already has a high cost (load/store memory, get/set global), it might be best to keep those as simple unspecialized cases. It is the simpler...
I found an interesting optimization while thinking about how wasm3 has a "register" parameter in it's opcodes and that `s1vm` was still using the stack for function parameters. On branch...