Re: The case of directly-executable parsers

Velco,


> What could be the reason for this parser performing so poorly? Or for
> the Bison parser performing so well? Has anyone got some recent
> observations with directly-executable vs. table driven recognizers -
> scanning (re2c?), parsing, tree-matching?


The generated code contains lots of jumps. I am guessing that
instruction pipeline never gets to crank up before it is flushed, also
all those jumps must be very bad for lookahead prediction and I dread
to think about the cache swapping that must be going on.


In the "good old days" jumps did not have such a big impact on
performance (well, at least on many processors). So I am guessing
that the excessive number of jumps are skewing the performance
characteristics, which did not happen on the processors used for the
previous timing comparisons.


Also gcc does not seem to be consistent in optimizing those switch ()
{ case L: goto Q; ...} constructs. Sometimes it turns the switch into
a nested-if, other times it populates the jump table with the
destination address of the goto.


Have you tried using dynamic profiling information to get gcc to tune
the generated code? That might result in some of the less frequently
executed code moved some place where it won't keep filling the cache.

Return to the comp.compilers page.
Search the comp.compilers archives again.