Re: Parser Cruft in gram.y

On 2012-12-20 15:45:47 +0100, Andres Freund wrote:
> On 2012-12-20 09:11:46 -0500, Robert Haas wrote:
> > On Thu, Dec 20, 2012 at 8:55 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> > > On 18 December 2012 22:10, Robert Haas <robertmhaas@gmail.com> wrote:
> > >> Well that would be nice, but the problem is that I see no way to
> > >> implement it.  If, with a unified parser, the parser is 14% of our
> > >> source code, then splitting it in two will probably crank that number
> > >> up well over 20%, because there will be duplication between the two.
> > >> That seems double-plus un-good.
> > >
> > > I don't think the size of the parser binary is that relevant. What is
> > > relevant is how much of that is regularly accessed.
> > >
> > > Increasing parser cache misses for DDL and increasing size of binary
> > > overall are acceptable costs if we are able to swap out the unneeded
> > > areas and significantly reduce the cache misses on the well travelled
> > > portions of the parser.
> >
> > I generally agree.  We don't want to bloat the size of the parser with
> > wild abandon, but yeah if we can reduce the cache misses on the
> > well-travelled portions that seems like it ought to help.  My previous
> > hacky attempt to quantify the potential benefit in this area was:
> >
> > http://archives.postgresql.org/pgsql-hackers/2011-05/msg01008.php
> >
> > On my machine there seemed to be a small but consistent win; on a very
> > old box Jeff Janes tried, it didn't seem like there was any benefit at
> > all.  Somehow, I have a feeling we're missing a trick here.
>
> I don't think you will see too many cache misses on such a low number of
> extremly simply statements, so its not too surprising not to see a that
> big difference with that.
>
> Are we sure its really cache-misses and not just the actions performed
> in the grammar that make bison code show up in profiles? I remember the
> latter being the case...

Hm. A very, very quick perf stat -dvvv of pgbench -S -c 20 -j 20 -T 20 later:
    218350.885559 task-clock                #   10.095 CPUs utilized        1,676,479 context-switches          #
0.008M/sec            2,396 cpu-migrations            #    0.011 K/sec          796,038 page-faults               #
0.004M/sec  506,312,525,518 cycles                    #    2.319 GHz                     [20.00%]  405,944,435,754
stalled-cycles-frontend  #   80.18% frontend cycles idle    [30.32%]  236,712,872,641 stalled-cycles-backend    #
46.75%backend  cycles idle    [40.51%]  193,459,120,458 instructions              #    0.38  insns per cycle
                               #    2.10  stalled cycles per insn [50.70%]   36,433,144,472 branches                  #
166.856 M/sec                   [51.12%]    3,623,778,087 branch-misses             #    9.95% of all branches
[50.87%]  50,344,123,581 L1-dcache-loads           #  230.565 M/sec                   [50.33%]    5,548,192,686
L1-dcache-load-misses    #   11.02% of all L1-dcache hits   [49.69%]    2,666,461,361 LLC-loads                 #
12.212M/sec                   [35.63%]      112,407,198 LLC-load-misses           #    4.22% of all LL-cache hits    [
9.67%]
     21.629396701 seconds time elapsed

So there definitely a noticeable rate of cache misses...

Greetings,

Andres Freund

--Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services