Re: ANSI-strict pointer aliasing rules - Mailing list pgsql-hackers
From | mark@mark.mielke.cc |
---|---|
Subject | Re: ANSI-strict pointer aliasing rules |
Date | |
Msg-id | 20060427144359.GA26734@mark.mielke.cc Whole thread Raw |
In response to | Re: ANSI-strict pointer aliasing rules (Martijn van Oosterhout <kleptog@svana.org>) |
Responses |
Re: ANSI-strict pointer aliasing rules
|
List | 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... 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 bindthem... http://mark.mielke.cc/
pgsql-hackers by date: