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

Re: ANSI-strict pointer aliasing rules

From: mark(at)mark(dot)mielke(dot)cc
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Taral <taralx(at)gmail(dot)com>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: ANSI-strict pointer aliasing rules
Date: 2006-04-27 14:43:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Apr 27, 2006 at 12:52:42PM +0200, Martijn van Oosterhout wrote:
> > Next time we have this discussion I wish someone would actually document 
> > the performance differences. IIRC most of what I have seen makes it at 
> > best marginal.
> I can imagine there are cases where the performance difference is
> nontrivial. Take this (somewhat contrived) example:
> int *i;
> char *c;
> while( *i < BIG_NUMBER )
> 	*i += *c;
> With strict aliasing, the compiler need only load *c once, without it
> needs to load it each time through the loop because it has to consider
> the possibility that 'i' and 'c' point to the same memory location.

> PostgreSQL doesn't actually have loops of this kind so it's not
> something we need worry about. And you can acheive all the benefits by
> ...

PostgreSQL might not - however PostgreSQL does use GLIBC, which does have
inlined or preprocessor defined code.

I haven't done the timings myself - but I think the optimization would
in theory apply to wider code than just the above. *c doesn't need to
be constant. It can be moving, as would be in the case of an strcpy()
or memcpy() implementation. As you pointed out, such things as
auto-vectorization become impossible if it cannot guarantee that the
data is different. The aliasing rules are one part, the 'restrict'
keyword is the more important part I would imagine. Not dissimilar to
the C compiler auto-assigning variables into registers, but allowing
for the designer to hint using the 'register' keyword.

In the modern day, I see fewer and fewer people using 'register', as
not only does the compiler tend to get it right, but the compiler
may actually do a better job. I could see the same thing being
true of auto-detect using aliasing rules vs 'restrict' keyword usage.

Even if it was only 1% - 2%. Isn't it worth it? :-) Especially for a
practice, that under existing code, has implementation defined
semantics. It might not work in the future, or with a new optimizer
mode that comes out, or a new platform...


mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)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...


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2006-04-27 14:49:02
Subject: Re: ANSI-strict pointer aliasing rules
Previous:From: Tom LaneDate: 2006-04-27 14:39:41
Subject: Re: ANSI-strict pointer aliasing rules

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