Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!ub!boulder!ccncsu!handel.CS.ColoState.Edu!flatau
From: flatau@handel.CS.ColoState.Edu (flatau)
Newsgroups: comp.unix.aix
Subject: Re: XLF optimizer unreliable, inappropriate for benchmarks
Keywords: fortran benchmark optimizer aix 6000
Message-ID: <9599@ccncsu.ColoState.EDU>
Date: 20 Sep 90 18:02:05 GMT
References: <384@nwnexus.WA.COM> <15433@cgl.ucsf.EDU>
Sender: news@ccncsu.ColoState.EDU
Reply-To: flatau@handel.UUCP (flatau)
Organization: Colorado State University, Fort Collins, CO  80523
Lines: 61


>
>However, until the XLF optimizer can be trusted, realistic
>benchmarks should be compiled with optimization OFF.  It
>doesn't matter how fast the machine is if the results are wrong.

Yes!

>>Nonsense.

???



>I'm including a short fortran program that demonstrates an
>optimizer bug that one of our applications people discovered.
>For the time being, I will not use the optimizer, period.
>It's not worth the grief.

Yes, we have found similar problems.

>>   I've found optimizer bugs on just about every machine that I've
>>put in a lot of time with.   They happen; that's the price you pay
>>for the extra speed that the optimizer provides, and that's why
>>software should have validation suites.

I don't agree. You pay for the optimizer not for its bugs.


>>If you don't validate your
>>code whenever the compiler, libs, O/S, hardware, or your own code
>>changes, you take your chances.  This is true on every machine, although
>>it may be more true on some than on others.

It is indeed possible to run the code with and without optimization
and compare results. Or to compare the results with that produced on other
machine. But there are applications (for example
CPU or memory intensive codes) where such comparison is not trivial
both economically and timewise.

>>I generally split up
>>large applications into numerically intensive portions and "all the rest",
>>and only optimize the numerically intensive part.   This provides a
>>lot of protection against optimizer bugs.   

Well, the point is that the computer is to save us time and not to deal
with its bugs by splitting the code or whatever.
Unfortunatelly it is true that the XLF optimizer doesn't work properly.
We run into subtle problem with the Discrete Dipole Approximation
code. The results were only slightly off from the
runs on another machine. We spent a lot of time tracing the problem
(converting to double, etc). The optimized version runs if the  main
program is compiled independently and without optimization!
However I am still not positive if the change of dimensions, say,
will result in still correct answers. I can't spend my life
checking answers on another computer each time I run application
on RISC6000.

One would hope that IBM puts its act together and fixes the optimizer.

Peter