Re: ANSI-strict pointer aliasing rules

Поиск
Список
Период
Сортировка
От mark@mark.mielke.cc
Тема Re: ANSI-strict pointer aliasing rules
Дата
Msg-id 20060427144359.GA26734@mark.mielke.cc
обсуждение исходный текст
Ответ на Re: ANSI-strict pointer aliasing rules  (Martijn van Oosterhout <kleptog@svana.org>)
Ответы Re: ANSI-strict pointer aliasing rules  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ANSI-strict pointer aliasing rules
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ANSI-strict pointer aliasing rules