Re: ANSI-strict pointer aliasing rules

On Thu, Apr 27, 2006 at 10:49:02AM -0400, Tom Lane wrote:
> mark(at)mark(dot)mielke(dot)cc writes:
> > Even if it was only 1% - 2%. Isn't it worth it? :-)
> No. According to the ancient saying, "I can make this program
> arbitrarily fast ... if it doesn't have to give the right answer".
> Percentage-point improvements are not worth the risk of introducing
> hard-to-find, compiler-and-hardware-dependent bugs.

Addressing the aliasing rule concerns raised by the compiler, at least
in theory, is improving the compatibility of the program, and reducing
the number of bugs that may be exposed under unusual circumstances. If
PostgreSQL isn't alias safe - it means that there is casting
happening, that is not generally accepted as valid, minimizing the
optimization potential of the code, and certainly not guaranteed to be
correct. Every cast in C has the potential to contain bugs today, or
tomorrow when somebody changes the lvalue or rvalue. If the types are
incompatible, according the compiler, the odds of a bug happening today
or tomorrow become greater.

If you are worried about PostgreSQL making use of the optimization
potential - and suggesting that by PostgreSQL making this impossible
currently, that you are preventing a compiler-and-hardware-dependent
bug, I strongly disagree. If most code is compiled with the aliasing
rules enabled in the optimizer, and your code is compiled with the
aliasing rules disabled, then you are using the lesser used
optimization paths in the compiler, actually raising the likelihood of
such a compiler bug being exposed. Compilers do have bugs - and by
choosing to use the non-standard optimization models, the chance of
you finding it first increases. You don't really want to be first.
You want the regression testing of the compiler to be first. :-)

> Show me how to find/prevent those bugs, and I'm all for going with
> the stricter rules. But you're so far off base with the above argument
> that I wonder whether we understand each other at all.

I think we can agree on the intrusiveness of the change needing to
be linear or less to the value of the change. If the fix is simple,
and it generates a 1% - 2% gain - you are buying both performance,
and correctness. Personally, I value correctness. I think some would
value performance though.

We're both playing opposite roles, to lead to a balanced discussion,
which is good. Not off base. Contrary. How could you expect to have
a balanced discussion otherwise? :-)

Cheers,
mark

--
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...

http://mark.mielke.cc/