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 <si...@2ndquadrant.com> wrote:
> > > On 18 December 2012 22:10, Robert Haas <robertmh...@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.008 M/sec
2,396 cpu-migrations # 0.011 K/sec
796,038 page-faults # 0.004 M/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.212 M/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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
