Re: Compile speed: Pascal(Delphi) vs C++

Robert A Duff <bobduff@shell01.TheWorld.com> writes:


> Optimization sometimes introduces new bugs.


I would hate to think that compiler writers make optimizations that
break language semantics. I know this can happen by mistake and that
earlier compilers were notorious for having buggy optimizations, but
with modern optimization techniques that shouldn't happen.


I have a feeling that in many cases optimization (in modern compilers)
not so much introduce bugs as reveal cases where the programmer made
unwarranted assumptions about language semantics, such as order of
computation, arithmetic precision, and other things.


I recall one such experience: I wrote a program (in C) that included a
function to find the shortest edge of an irregular tetrahedron with
vertices A, B, C and D. It did that roughly by


shortest(A,B,C,D) =
    if |A-C| < |A-B| then shortest (A,C,B,D)
    else if |A-D| < |A-B| then shortest(A,D,C,B)
    else if |B-C| < |A-B| then shortest(B,C,A,D)
    else if (more tests)
    else (A,B)


Not very efficient I grant you, but that wasn't the problem. The
problem was that optimization combined a*b+c (part of the |A-B|
computation) into one MAC instruction, which changed the precision
such that you could have that |A-C|<|A-B| and then after swapping B
and C (i.e., C'=B, B'=C), you would in the next call also have
|A-C'|<|A-B'|, which caused infinite recursion.


I don't blame the compiler. I was foolish to treat floating-point
numbers as exact, i.e., expecting that if |A-B|=|A-C|, then I wouldn't
get a "<" result.


Torben Mogensen

Return to the comp.compilers page.
Search the comp.compilers archives again.