4 ms·
>> 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? U
by alok-g 6y ago
>> 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.
- ncmncm 6y agoOptimized 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 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.
- krizhanovsky 6y agoThe benchmarks https://github.com/ncm/computed-goto/blob/master/benchmarks/trivial.cpp 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 http://www.tempesta-tech.com/research/http_str.pdf - slide 23 discusses that the goto FSM makes sense for _hundreds_ of states.
- ncmncm 6y agoThe number of states is irrelevant. An optimized tail call is achieved with, exactly, a single branch instruction.