Skip site navigation (1) Skip section navigation (2)

Re: Inlining comparators as a performance optimisation

From: Greg Stark <stark(at)mit(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inlining comparators as a performance optimisation
Date: 2011-09-21 16:35:41
Message-ID: CAM-w4HPw=A_weJVKpCHOTf-H9tu9AZNhY7Qfzf89-mnteuV8xA@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Wed, Sep 21, 2011 at 5:23 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> None of that stuff is inlinable or constant-foldable today, nor would it
> be with the patch that Peter was proposing AFAICS, because none of the
> flags will ever be compile time constant values.

I was referring to transformations like this which I believe compilers
are already capable of doing:

v = ...;
while (...)
  if (v) {
    if (a < b) ... else ....;
  } else {
    if (a > b) ... else ...;
  }

turning it into code that looks like:

if (v) {
 while (....)
   if (a<b) ... else ...;
} else {
  while (....)
    if (a>b) ... else ...;
}

which may not look like much -- especially with branch prediction --
but then it's much more likely to be able to unroll the loop and do
clever instruction scheduling and so on than if there's an extra
branch in the middle of the loop. But if there's a function call to an
external function called through a function pointer in the middle of
the loop then the whole endeavour would be for naught.



-- 
greg

In response to

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-09-21 16:49:12
Subject: Re: Is there really no interest in SQL Standard?
Previous:From: Florian PflugDate: 2011-09-21 16:34:24
Subject: Re: Hot Backup with rsync fails at pg_clog if under load

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group