Re: profile-guided opt. w/ GCC

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

In response to

Browse pgsql-hackers by date

  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