[LCP]Rounding questions

[Greg Black]

Chuck Martin wrote:

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

OK, I think it's clear that you have to drop round() for now.

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

Fair enough, but it's still best to work with code that is as
close as possible to the original -- it avoids errors that you
might have inadvertently introduced yourself.

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

The next step would be to try turning them off selectively.  If
there are a dozen .o files, it may be only one that has a bug
introduced by the optimiser.  Try each one separately with the
optimiser and see how it goes.

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

I'd tackle this in several parts.  First, try the suggestion
above about possibly optimising most of the code.  Then test its
performance.  If it's fast enough on modern hardware, stop.  If
it's actually too slow (which is unlikely, because optimisers
are much better at introducing bugs than at generating faster
code), profile it to see where the time is being spent.  Then,
armed with the profiling data, have a good look at the places
that take up most of the time and see if better algorithms would
help.

Certainly, unless it's absolutely huge, don't even think about
the size of the executable -- modern disk is almost free and
it's not worth accepting bugs to save a few bytes of disk.

In general, turning off buggy optimisation is a far better
approach than "working around" bugs with unnecessary calls in
the code.  It's a rational response to a real bug, while the
other approach smacks of mysticism.

Greg