Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!dca6-feed2.news.digex.net!intermedia!netnews.jhuapl.edu!not-for-mail
From: jonathan.des...@jhuapl.edu
Newsgroups: comp.lang.fortran
Subject: Re: more precision in g77 optimized code? ***UPDATE***
Date: Tue, 12 Jun 2001 09:44:36 -0400
Organization: JHU/APL
Lines: 60
Message-ID: <3B261CC4.609502B6@jhuapl.edu>
References: <3B17F047.13CB9ECA@jhuapl.edu> <3B184FEE.B1BC7003@netwood.net> <3B1BB40D.C2F2CF4B@jhuapl.edu> <3B1C962B.779AEA0A@nag.co.uk> <3B1D246A.24F3350C@jhuapl.edu> <u7mkf9.q2d.ln@robpc1.telus.net> <3B1FA697.949A2AAC@nag.co.uk> <3B20D29F.2FCAFBD6@uabmc.edu> <8dd4g9.df4.ln@robpc1.telus.net>
NNTP-Posting-Host: desenjt1.jhuapl.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: houston.jhuapl.edu 992353426 14455 128.244.68.35 (12 Jun 2001 13:43:46 GMT)
X-Complaints-To: usenet@houston.jhuapl.edu
NNTP-Posting-Date: 12 Jun 2001 13:43:46 GMT
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3 i686)
X-Accept-Language: en

Rob Komar wrote:
> Yes, I spent quite a bit of time a few years ago (when g77 was just becoming
> stable) trying to verify our g77/x86 builds of a large Monte Carlo particle
> physics simulation program by comparing the results against those generated
> by commercial workstations (Sun, Dec OSF/1,...).  My theory was that if I
> could get the same results with g77/x86 as the workstations got, I could
> trust the (still proclaimed as a beta) g77 compiler.  I tinkered with the
> FPU control word, and even hacked the libc math library to always store/load
> the returned values from intrinsic functions to consistently truncate them,
> but never got exactly the same results as the other machines.  But then
> again, the Sun and Dec results also differed somewhat, not only between
> each other, but between themselves at different levels of optimization.
> My guess was that I was seeing the tiny differences produced by performing
> the arithmetic operations in different order at different levels of
> optimization for calculations produced by the same compiler, and even
> bigger differences caused by intrinsic functions returning different
> results on different architectures.  Monte Carlo simulations, if run
> long enough, will branch into completely different histories if the
> calculations aren't identical, so they are particularly sensitive to
> even tiny differences in FPU calculations.  In the end, I gave up on
> trying to verify the results in this fashion, and fell back on checking
> that the results matched statistically.

Thanks for your reply. I am glad others have tried similar tests as I
have, with similar results. I too have by now decided to compare results
after many runs as the validation rather than comparing numbers
throughout a single run. I will say however, that comparing each
individual run was useful because it pointed out some places in the code
which are not very forgiving to small differences and allowed me to
clean a few places up. 

So far, statistically, g77/x86 and Solaris f77/SPARC seem to be very
close -- I expected a bigger difference. I will do some more tests
though to be sure.

> I seem to recall that the Sun compiler had a switch to make sure that the
> FPU calculations were identical at various levels of optimization by
> fixing the arithmetic operations to some consistent order. 

In the version of the Solaris compiler we are using (f77 which came with
Workshop 5.0), optimization is producing exactly the same results as
unoptimized. Perhaps the switch you are reffering to is now the
standard. 

>                                                            That's the
> kind of effort you have to go to to achieve `standard' results.  If
> you don't, how do you know that the small differences (those in the
> least significant bit position that started this whole thread) are
> due to `bugs' rather than the mundane differences between even IEEE-754
> compliant calculations?

That's exactly what disturbed me about the observations I made in the
first place, and the reason I continued to pursue what was causing
differences until I could at least justify them.

--
Jonathan DeSena
Johns Hopkins University Applied Physics Laboratory
Power Projection Systems Department
Aviation Systems Group