4 ms·
Do you have benchmarks for this? The linked paper only evaluates performance of optimizations applied on top of this idea, and the idea vs. Rhino. Besides, not
by LnxPrgr3 11y ago
Do you have benchmarks for this? The linked paper only evaluates performance of optimizations applied on top of this idea, and the idea vs. Rhino.
Besides, not all bytecode interpreters are made equal: http://vvm.lip6.fr/publications/9806PLDI.ps.gz http://vvm.lip6.fr/publications/9806PLDI.ps.gz.
- JoeAltmaier 11y agoMy data is old - various control languages, BASIC, RPN style expression engine. Each time about the same performance. Go ahead and implement a bytecode machine, but you lose two ways: the time to write that extra engine, and the loss of semantics. In the interplet (ok, AST) interpreter, you can add debugging features that 'understand' the intent e.g. still know a loop is a loop. That's cool and powerful.
- sklogic 11y agoIt's better to know that loop is a loop just from a CFG, even if it's implemented with a goto and if. In this case stripping source language semantics may be useful.
- JoeAltmaier 11y agoSo true! A peephole optimizer can operate on constructs no matter how they're generated, and streamline them (use custom objects for common/slow cases). But for debugging, its nice to offer diagnostic or control features (e.g. execute 1000 times then break).
- sklogic 11y agoYou still have your loops in CFG, identifying back edges and extracting loop induction variables is mechanical. And you can lower any amount of debugging information out of your high level AST structures. No need to stay in AST to have it all.