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

torbenm@diku.dk (Torben Ęgidius Mogensen) writes:


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


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


> 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

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