golder@nwnexus.WA.COM (Warren Jones) (09/20/90)
Thanks to ichihara@rkna50.riken.go.jp (Takashi Ichihara) for posting detailed benchmark results for the Power Station 530. 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. 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. Incidentally -- does anyone know if all the XL languages (including C and Pascal) use the same optimizer? Until I'm sure of the answer, I'm not using the C optimizer either. ------------------------ cut here --------------------------- #! /bin/sh # This is a shell archive, meaning: # 1. Remove everything above the #! /bin/sh line. # 2. Save the resulting text in a file. # 3. Execute the file with /bin/sh (not csh) to create the files: # README # bug.f # Makefile # bugdemo # This archive created: Wed Sep 19 12:54:26 1990 export PATH; PATH=/bin:$PATH echo shar: extracting "'README'" '(884 characters)' if test -f 'README' then echo shar: will not over-write existing file "'README'" else sed 's/^X//' << \SHAR_EOF > 'README' X XThis is a test program that demonstrates a bug in the XLF fortran Xcompiler under AIX 3.1. The applications programmer who discovered Xthe problem has tried a number of variations, and this code seems to Xbe the minimum required to reproduce the bug in a predictable manner. X XIBM problem number: 1X991 X XWe are running AIX 3.1 on a RISC6000-530. XHere is some version information produced by "lslpp -h": X XOption Name State Event Date/Time Release User Name X-------------------- ---------- ---------- --------- --------------- ---------- Xxlfcmp.obj ACTIVE COMMIT 07/14/90 01.01.0000.0000 root Xxlfrte.obj ACTIVE COMMIT 07/14/90 01.01.0000.0000 root X XWarren Jones Sept 5, 1990 XGolder Associates Inc. X4104 148th Ave NE (206) 883-0777 XRedmond, WA 98052 email: golder@nwnexus.wa.com X SHAR_EOF if test 884 -ne "`wc -c < 'README'`" then echo shar: error transmitting "'README'" '(should have been 884 characters)' fi fi # end of overwriting check echo shar: extracting "'bug.f'" '(1017 characters)' if test -f 'bug.f' then echo shar: will not over-write existing file "'bug.f'" else sed 's/^X//' << \SHAR_EOF > 'bug.f' Xc----------------------------------------------------------------- X program bug Xc Xc This code demonstrates an optimizer bug in the XLF fortran Xc compiler under AIX 3.1. It seems to be the minimum required Xc to reproduce the bug in a predictable manner. Compile with and Xc without the XLF optimizer turned on, and compare the results. Xc Xc Warren Jones Sept 5, 1990 Xc Golder Associates Inc. Xc 4104 148th Ave NE (206) 883-0777 Xc Redmond, WA 98052 email: golder@nwnexus.wa.com Xc----------------------------------------------------------------- X X integer*4 b, i, k, m, n X logical*4 test Xc X test = .true. X m = 0 X k = 0 X i = 0 Xc X 10 continue X i = i + 1 X if (test) then X do 2 n = 1, 3 X m = m + 1 X k = k + 1 X b = k + 1 X 2 continue X write (*,'(a,i6)')' k = ',k X write (*,'(a,i6)')' k - 1 = ',k - 1 X end if X if (i .lt. 2) goto 10 Xc X stop X end X SHAR_EOF if test 1017 -ne "`wc -c < 'bug.f'`" then echo shar: error transmitting "'bug.f'" '(should have been 1017 characters)' fi fi # end of overwriting check echo shar: extracting "'Makefile'" '(223 characters)' if test -f 'Makefile' then echo shar: will not over-write existing file "'Makefile'" else sed 's/^X//' << \SHAR_EOF > 'Makefile' X#! /bin/make -f X# X# Makefile to demonstrate an optimizer bug X# in the XLF fortran compiler under AIX 3.1. X Xbug.out : bug nobug X bugdemo 2>&1 | tee bug.out X Xbug : bug.f X xlf -O -o $@ bug.f X Xnobug : bug.f X xlf -o $@ bug.f X SHAR_EOF if test 223 -ne "`wc -c < 'Makefile'`" then echo shar: error transmitting "'Makefile'" '(should have been 223 characters)' fi fi # end of overwriting check echo shar: extracting "'bugdemo'" '(100 characters)' if test -f 'bugdemo' then echo shar: will not over-write existing file "'bugdemo'" else sed 's/^X//' << \SHAR_EOF > 'bugdemo' X#! /bin/sh X Xecho Xecho "NOBUG (Optimization OFF)"; nobug X Xecho Xecho "BUG (Optimization ON) "; bug X SHAR_EOF if test 100 -ne "`wc -c < 'bugdemo'`" then echo shar: error transmitting "'bugdemo'" '(should have been 100 characters)' fi chmod +x 'bugdemo' fi # end of overwriting check # End of shell archive exit 0 -- ---------------------------------------------------------------- Warren Jones <golder@nwnexus.wa.com> Golder Associates Inc. (uucp: uunet!nwnexus!golder) 4104 148th Avenue NE (206) 883-0777 Redmond, WA 98052, USA
seibel@cgl.ucsf.edu (George Seibel) (09/20/90)
In article <384@nwnexus.WA.COM> golder@nwnexus.WA.COM (Warren Jones) writes: > >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. Nonsense. Realistic benchmarks are expected to produce answers that can be validated. I'm not interested in unoptimized benchmarks; If I'm buying an optimizer, I want to know how well it works. *IF* a particular benchmark can't pass because of an optimizer bug, then compile at a lower level of optimization, but say so. >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. 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. 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. 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. George Seibel, UCSF seibel@cgl.ucsf.edu
flatau@handel.CS.ColoState.Edu (flatau) (09/21/90)
> >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
3003jalp@ucsbuxa.ucsb.edu (Applied Magnetics) (09/21/90)
In article <384@nwnexus.WA.COM> golder@nwnexus.WA.COM (Warren Jones) writes: > [ gives a short Fortran program that optimizes incorrectly ] >Incidentally -- does anyone know if all the XL languages (including >C and Pascal) use the same optimizer? Until I'm sure of the >answer, I'm not using the C optimizer either. Well, I transliterated your example to C and got the same behaviour. Congratulations to your programmer for producing such a small example. #include <stdio.h> main() { int b, i, k, m, n; int test; test= 1; i= k= m= 0; do { i++; if(test) { for(n= 0; n<3; n++) { m++; k++; b= k+1; } printf("k= %d, k-1= %d\n", k, k-1); } } while(i<2); } -- P. Asselin, Applied Magnetics Corp.
frank@gremlin.austin.ibm.com (Frank Feuerbacher) (09/21/90)
> One would hope that IBM puts its act together and fixes the optimizer.
I hope that you have called the problem in. Problems can not be fixed unless
the person who can fix it knows about it. Who knows (I don't), they may even
have a fix that you can try?
Disclaimer: I don't speak for my employer and they don't speak for me.