[LCP]Rounding questions

[Mike & Penny]

a) Whether optimization is to increase speed or decrease space depends upon
the thoughts of the particular  people designing the optimization process.
SOME forms of optimization (for example, avoiding address loads from memory
when the right address is already in some (other) register) save both. But
in general, one trades space for time and vice versa (in line code is faster
than function calls, but takes space, etc.).

b) If a bug appears when optimization is turned on that does not necessarily
mean it is a bug in the optimization process. Remember, each compiler
represents ONE possible implementation of a high level language, and
sometimes a clumsy, perform no optimizations compiler can "cover up" coding
errors. That does not make it a "better" or less bugged compiler. The only
promise supposedly being made is that correct code will compile to execute
correctly. Incorrect code MAY still compile and execute correctly (as the
programmer thinks it should) and a compiler is not supposed to be judged
either better nor worse for how it behaves with incorrect code.

Sorry, I am too inexperienced doing serious debugging of C to be able to
give you examples of this.But I'd have no trouble showing you COBOL code
with errors that "works" or doesn't depending upon the compiler version.
Needless to say bugs like this leave programmers scratching their heads and
back before I retired, they'd end up at my desk saying  "But we haven't
changed the source code at all, just recompiled with the new compiler
version (or a different option), and now it doesn't work. Must be something
wrong with that new compiler (that option)."

Michael
    Who has of late been too busy with some consulting work to do more than
lurk so I wouldn't be able to debug that code to explain where the (actual)
bug is. But I bet it's not the compiler. BTW, floating point math in finite
representations is VERY tricky and not at all easy to do in portable
fashion. Although this is a C list, the problem (how to handle such math) is
a general problem in computing. The first thing you have to understand is
that your programs shouldn't depend on EXACT tests but instead on some
"fuzz" and the order in which calculations are performed should be assumed
to matter. In other words, two calculations with different order of
operations that should give the same result according to the rules of
Mathematics may not do so when performed by the computer (finite
approximations).





----- Original Message -----
From: Chuck Martin <nrocinu at myrealbox.com>
To: <linuxcprogramming at lists.linux.org.au>
Sent: Friday, September 06, 2002 4:37 PM
Subject: Re: [LCP]Rounding questions


> On Fri, Sep 06, 2002 at 08:57:34PM +1000, Greg Black wrote:
> > Chuck Martin wrote:
> > | On Fri, Sep 06, 2002 at 07:21:46AM +1000, Greg Black wrote:
> > | > panoply.  None of the BSD systems I have access to here has
> > | > this.
> > |
> > | If this is true, I probably don't want to use round() then.
> >
> > I'd say that was a good decision :-)
>
> Well, since I've taken over maintaining this public domain program,
> I've received e-mail from users of both FreeBSD and OpenBSD that
> are using it, and I sure don't want to break it for them.
>
> >      part of the program.  If you can't create a small sample
> >      program with the problem, it usually means that you haven't
> >      yet understood the nature of the problem.
>
> I'll have to agree with that.
>
> > It's best to track this down through the most original code that
> > can illustrate the problem in case it's a bug that needs to be
> > reported to the original author.
>
> This program has a list of authors a mile long, and I don't have any
> idea how to contact them (most in the list have no e-mail addresses,
> and the ones that do have the old bang path style addresses), or to
> determine which one is responsible for any particular section of the
> code.
>
> > present.  First, and always when debugging, make sure that all
> > compiler optimisations are OFF.  If the problem disappears, it's
> > an optimiser bug, so you're done.
>
> I hadn't considered the possibility that it might be related to the
> compiler optimisations.  Turning off the optimisations seems to have
> cured the problem, so I guess I'll have to leave them off in the
> Makefile.
>
> > As somebody else mentioned, FPU registers and C doubles are not
> > the same size in i386 machines, so subtle differences may arise
> > because of that.  And sometimes math library functions do odd
> > things unless you turn the right knobs (see the IEEE-754 doco
> > for your system for more on this).
>
> Yes, I've run into the FPU problems before, and ended up leaving
> a couple of unnecessary fflush(stdout)'s in the code to force
> the FPU stack to be popped, which I wasn't happy with, but I didn't
> know of another solution.  I hadn't thought that it might be related
> to optimisation in the compiler.  Now that I have optimisation turned
> off, I tried removing those, and the old bugs are gone, too.  Of
> course, the size of the binary is also increased by about 24%, and
> I'm not sure about the speed.  Is it better to leave optimisation
> off, or to leave in unnecessary system calls that force things to
> work with optimisation on?  (Of course, I had those "unnecessary"
> system calls documented as to why they were there so no one would
> try to remove them in the future.)
>
> Chuck
>
>
> _______________________________________________
> This is the Linux C Programming List
> :  http://lists.linux.org.au/listinfo/linuxcprogramming List
>