Hacker News Reader

>> It is very unlikely that the computed gotos make the parser faster than using standard features of a more powerful language.

Can you explain more on how? Use case I have in mind is bytecode interpretation where computed goto should be a big help.

View on HN

Optimized tail calls are effectively the same as computed goto, but are a Standard feature. Or, rather, don't require non-standard syntax. A program that relies on the optimization built by a compiler that failed to implement it--which is allowed--would not be expected to run well.

https://github.com/ncm/computed-goto

The "more powerful language" part is to get language-level tools to compose parser combinators, ultimately resolving down to tail calls.

The benchmarks https://github.com/ncm/computed-goto/blob/master/benchmarks/... benchmark is not applicable to this discussion because it compares _too_ small state machines. I reference my talk and presentation once more: http://www.tempesta-tech.com/research/http_str.pdf - slide 23 discusses that the goto FSM makes sense for _hundreds_ of states.

The number of states is irrelevant. An optimized tail call is achieved with, exactly, a single branch instruction.

Reply on news.ycombinator.com