News for hackers. Stuff that matters.
Re:Building Fast Interpreters in Rust by RReverser on Monday March 04, 2019 @01:28PM (#19303797)
More control is, as usual, less ability for automatic optimisations. For example, Rust uses knowledge of tag + data combinations for niche-filling enums where possible (and more similar optimisations to come), while LLVM can use this information to more easily deduce which branches are unreachable.

As for alignment - you can control it in Rust enums too, if you wish, by putting custom aligned structures as variant payloads.

In general, I'm sure it would be possible to achieve same (or, who knows, maybe even slightly better) performance than AST interpretation with manual tweaking, but the closure-based approach proved to give significant wins out of the box, while being more elegant to maintain and extend over time.

Re:Building Fast Interpreters in Rust by ridiculous_fish on Monday March 04, 2019 @01:57PM (#19304122)
In a bytecode interpreter's loop, you want your language to be little more than a fancy assembler. Exotic techniques become viable and even critical for performance: computed goto, misaligned reads, pointer arithmetic, unchecked type conversions, etc. This is one place where you want to tightly control your machine code.
Re:Building Fast Interpreters in Rust by RReverser on Monday March 04, 2019 @02:21PM (#19304357)
Oh, sure, if you're willing to go to unsafe techniques, you can go straight to a template JIT as well. But, for us, the balance is important, and safety is probably even more important than further wins in performance (which we can still easily get with algorithm-level optimisations before doing anything unsafe).