MAMaxBarraclough·Jan 14, 2022
With respect you've ignored the point I was making. There exist several Forth engines with native code-compilation, for instance VFX Forth, SwiftForth, and iForth.
> Typically the C version outperformed the Forth version by 3:1 or better, and I would not have known how to bridge that gap.
With a threaded-code Forth interpreter I'd expect the C version to outperform it by something closer to 5:1, so 3:1 doesn't sound too bad. The only way you can close the gap is with good quality native-code compilation.
> Nowadays with far larger caches Forth might do better, I haven't really worked with it for years.
It's interesting how advances in CPU architecture change the relative performance of the different threading strategies. This has been nicely studied by the gforth folks. [0][1] Threaded-code interpreters still easily lose to optimising nat
Read the rest
ive-code compilers though, [2] and I expect they always will.
More on how Forth collides with low-level CPU matters: [3][4][5]
[0] https://www.complang.tuwien.ac.at/forth/threading/
[1] https://www.complang.tuwien.ac.at/forth/threaded-code.html
[2] https://github.com/ForthHub/discussion/issues/88#issuecommen...
[3] The Behavior of Efficient Virtual Machine Interpreters on Modern Architectures - https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.12...
[4] Branch Prediction and the Performance of Interpreters -
Don't Trust Folklore https://hal.inria.fr/hal-01100647/document
[5] Optimizing Indirect Branch Prediction Accuracy in Virtual Machine Interpreters - https://www.scss.tcd.ie/David.Gregg/papers/toplas05.pdf