From: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
---|---|
To: | Neil Conway <neilc(at)samurai(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: profile-guided opt. w/ GCC |
Date: | 2004-09-30 10:58:28 |
Message-ID: | 20040930105828.GB69315@xs4all.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 30, 2004 at 07:07:27PM +1000, Neil Conway wrote:
> I think it would be cool to add support for PGO to PostgreSQL's build
> system (for 8.1). There are a lot of situations where PostgreSQL is
> compiled once, and then used for weeks or months (compilations for
> inclusion in a distro being the extreme example). In that kind of
> situation, trading some additional compile-time for even a small
> improvement in run-time performance is worthwhile, IMHO.
It's some time ago now, but a group at the Universitat Politecnica de
Catalunya (including my thesis advisor Alex Ramirez and our databases
specialist Josep Larriba-Pey) has done a case study on something similar,
using PostgreSQL as their case study.
What they researched was a code reordering algorithm that minimized both
taken branches and I-cache clashes. The scheme was quite aggressive, even
going so far as to coallocate code in some functions with code in their
most frequent callers. The study also includes a characterization of the
I-miss and execution intensities of the backend, in a neat matrix with
the major functions on one axis and the stage from which they're invoked
on the other.
The paper may be enlightening. Just a moment while I google for it...
...Got it. Here's the paper:
http://research.ac.upc.es/CAP/hpc/Papers/1999/aramirez1999aC.pdf
And here's the Citeseer entry:
http://citeseer.ist.psu.edu/context/163268/0
Jeroen
From | Date | Subject | |
---|---|---|---|
Next Message | John DeSoi | 2004-09-30 12:00:45 | looking for pgEdit beta testers |
Previous Message | Gaetano Mendola | 2004-09-30 10:16:04 | FlushRelationBuffers error |