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

torbenm@diku.dk (Torben Ęgidius Mogensen)
8 Dec 2003 00:15:45 -0500

          From comp.compilers

Related articles
[4 earlier articles]
Re: Compile speed: Pascal(Delphi) vs C++ robert.thorpe@antenova.com (Rob Thorpe) (2003-11-21)
Re: Compile speed: Pascal(Delphi) vs C++ vbdis@aol.com (2003-11-21)
Re: Compile speed: Pascal(Delphi) vs C++ randyhyde@earthlink.net (Randall Hyde) (2003-11-21)
Re: Compile speed: Pascal(Delphi) vs C++ marcov@stack.nl (Marco van de Voort) (2003-12-03)
Re: Compile speed: Pascal(Delphi) vs C++ marcov@stack.nl (Marco van de Voort) (2003-12-03)
Re: Compile speed: Pascal(Delphi) vs C++ bobduff@shell01.TheWorld.com (Robert A Duff) (2003-12-03)
Re: Compile speed: Pascal(Delphi) vs C++ torbenm@diku.dk (2003-12-08)
Re: Compile speed: Pascal(Delphi) vs C++ joachim.durchholz@web.de (Joachim Durchholz) (2003-12-08)
Re: Compile speed: Pascal(Delphi) vs C++ rygNOSPAM@gmx.net (Fabian Giesen) (2003-12-08)
Re: Compile speed: Pascal(Delphi) vs C++ bobduff@shell01.TheWorld.com (Robert A Duff) (2003-12-13)
Re: Compile speed: Pascal(Delphi) vs C++ postmaster@paul.washington.dc.us (Paul Robinson) (2004-02-04)
| List of all articles for this month |

From: torbenm@diku.dk (Torben Ęgidius Mogensen)
Newsgroups: comp.compilers
Date: 8 Dec 2003 00:15:45 -0500
Organization: Department of Computer Science, University of Copenhagen
References: 03-11-048 03-11-078 03-12-023
Keywords: practice, Pascal, C
Posted-Date: 08 Dec 2003 00:15:45 EST

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


Post a followup to this message

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