From: mark@mark.mielke.cc
To: Martijn van Oosterhout <kleptog@svana.org>
Cc: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Ron Peacetree <rjpeace@earthlink.net>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] A Better External Sort?
Date: Tue, 4 Oct 2005 13:02:53 -0400
Message-ID: <20051004170253.GA26380@mark.mielke.cc> (raw)
In-Reply-To: <20051004152336.GI17589@svana.org>
References: <20051002123240.GA30492@svana.org>
<20051002193835.GJ30492@svana.org>
<1128376292.8603.142.camel@localhost.localdomain>
<20051004100441.GC17589@svana.org>
<1128425094.8603.296.camel@localhost.localdomain>
<20051004122443.GF17589@svana.org>
<7788.1128434784@sss.pgh.pa.us>
<20051004143041.GH17589@svana.org>
<1128437813.8603.305.camel@localhost.localdomain>
<20051004152336.GI17589@svana.org>
On Tue, Oct 04, 2005 at 05:23:41PM +0200, Martijn van Oosterhout wrote:
> On Tue, Oct 04, 2005 at 03:56:53PM +0100, Simon Riggs wrote:
> > I've been using gcc 3.4 and saw no warning when using either "-Winline"
> > or "-O3 -Winline".
> Ok, I've just installed 3.4 and verified that. I examined the asm code
> and gcc is inlining it. I concede, at this point just throw in -Winline
> and monitor the situation.
> As an aside, the *_getattr calls end up a bit suboptimal though. It's
> producing code like:
> cmp attlen, 4
> je $elsewhere1
> cmp attlen, 2
> je $elsewhere2
> ld byte
> here:
> --- much later ---
> elsewhere1:
> ld integer
> jmp $here
> elsewhere2:
> ld short
> jmp $here
> No idea whether we want to go down the path of hinting to gcc which
> size will be the most common.
If it will very frequently be one value, and not the other values, I
don't see why we wouldn't want to hint? #ifdef it to a expand to just
the expression if not using GCC. It's important that we know that the
value would be almost always a certain value, however, as GCC will try
to make the path for the expected value as fast as possible, at the
cost of an unexpected value being slower.
__builtin_expect (long EXP, long C)
You may use `__builtin_expect' to provide the compiler with branch
prediction information. In general, you should prefer to use
actual profile feedback for this (`-fprofile-arcs'), as
programmers are notoriously bad at predicting how their programs
actually perform. However, there are applications in which this
data is hard to collect.
The return value is the value of EXP, which should be an integral
expression. The value of C must be a compile-time constant. The
semantics of the built-in are that it is expected that EXP == C.
For example:
if (__builtin_expect (x, 0))
foo ();
would indicate that we do not expect to call `foo', since we
expect `x' to be zero. Since you are limited to integral
expressions for EXP, you should use constructions such as
if (__builtin_expect (ptr != NULL, 1))
error ();
when testing pointer or floating-point values.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mark@mark.mielke.cc, kleptog@svana.org, simon@2ndquadrant.com, tgl@sss.pgh.pa.us, rjpeace@earthlink.net, pgsql-hackers@postgresql.org
Subject: Re: [PERFORM] A Better External Sort?
In-Reply-To: <20051004170253.GA26380@mark.mielke.cc>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox