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

Robert A Duff <>
13 Dec 2003 21:11:09 -0500

          From comp.compilers

Related articles
[7 earlier articles]
Re: Compile speed: Pascal(Delphi) vs C++ (Marco van de Voort) (2003-12-03)
Re: Compile speed: Pascal(Delphi) vs C++ (Marco van de Voort) (2003-12-03)
Re: Compile speed: Pascal(Delphi) vs C++ (Robert A Duff) (2003-12-03)
Re: Compile speed: Pascal(Delphi) vs C++ (2003-12-08)
Re: Compile speed: Pascal(Delphi) vs C++ (Joachim Durchholz) (2003-12-08)
Re: Compile speed: Pascal(Delphi) vs C++ (Fabian Giesen) (2003-12-08)
Re: Compile speed: Pascal(Delphi) vs C++ (Robert A Duff) (2003-12-13)
Re: Compile speed: Pascal(Delphi) vs C++ (Paul Robinson) (2004-02-04)
| List of all articles for this month |

From: Robert A Duff <>
Newsgroups: comp.compilers
Date: 13 Dec 2003 21:11:09 -0500
Organization: The World Public Access UNIX, Brookline, MA
References: 03-11-048 03-11-078 03-12-023 03-12-053
Keywords: performance, optimize
Posted-Date: 13 Dec 2003 21:11:09 EST (Torben Ęgidius Mogensen) writes:

> Robert A Duff <> writes:
> > Optimization sometimes introduces new bugs.
> I would hate to think that compiler writers make optimizations that
> break language semantics.

I hate it, too, but nonetheless, compilers do have bugs. Sometimes
these bugs are triggered by turning on optimization. Sometimes by
turning off optimization.

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

It shouldn't, but it does. Using "modern optimization techniques" is
all well and good, but it doesn't eliminate compiler bugs,

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

Quite true. When I said, "Optimization sometimes introduces new
bugs", I wasn't trying to place the blame. Those bugs could be
optimizer bugs, or they could be the programmer's fault. Either way,
turning on optimizations can cause the program being compiled to
misbehave. My point was simply that if you want to do development
using a no-optimize/debug build, but release an optimized version,
then you would be wise to have a nightly-run script that runs all your
regression tests in *both* modes.

Whether languages ought to have such nondeterministic semantics is
another question. Java tries to nail things down more precisely than
Ada or C, for example. With regard to order of evaluation of
arguments, for example.

I'm currently working on a tool that can (among other things) prove
statically that order of evaluation of arguments doesn't matter --
place certain restrictions on the arguments, and then you can be sure
that F(X, Y) produces the same results whether X or Y is evaluated

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

Yes, that's an example of what I was talking about. If you test the
optimized version on a regular basis, you have a good chance of
knowing which change triggered the problem. If you wait until the
project is done, and *then* turn on the optimizer, and your tests
don't work, it's hard to figure out why.

As a compiler writer, I've received bug reports that blamed the
compiler, when actually the programmer was at fault. Doesn't matter
-- the program didn't work.

- Bob

Post a followup to this message

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