a question and an answer about optimizing compilers; your chance to rebut

[David G. Hough on validgh]

berndatc1.chemie.uni-bielefeld.de asks...

> I am trying to install the LAPACK library (successor of LINPACK and EISPACK)
> in version 1.1 on an HP 9000/735 workstation under HP-UX 9.01 - and I am
> running into problems (too lengthy to describe here; basically, some of the
> test programs that come with the package fail miserably, and the extent of
> the failures depends critically on the compiler options used). Previously,
> we had HP 720's under HP-UX 8.xx, and I observed very similar problems then
> with LAPACK 1.0a/1.0b. At that time, I ascribed the problems to possible
> bugs in the compiler/software/hardware/..., but the new versions prove not
> to be much better.
> Now, the questions are:
> 1) Has anyone out there experienced similar problems?
> 2) What is the best solution available, if any?

and I answered...

> As for LAPACK, I have read that
> HP uses simple but fast algorithms for complex division that
> cause it to fail frequently with gratuitous
> intermediate overflow/underflow problems.
> All other Unix workstation vendors have adopted algorithms that are more
> robust and slower.

> Particularly at high levels of optimization using preprocessors
> (e.g. KAP which is built into HP, IBM, and SGI compilers, I think) you will run
> into many difficulties, some of which are due to the compilers and some to
> the source code to be compiled
> (although probably not the latter with LAPACK).   Basically you
> are doing quality assurance for the compiler vendors and the source coders.    
> SunPro compilers for SPARCstations tend to be more robust, so that even
> though the underlying hardware has a lower absolute speed limit, more of the
> potential performance may be actually available with reasonable effort.    
> But if
> you look at the compiler options listed in official SPEC performance reports,
> you'll find nothing to reassure you about any of the workstation vendors.
> Compiling with a simple "f77 -O" has nothing to do with published SPEC
> numbers.

> There are many issues here, of language definitions, existing bodies of source
> code, kluges for SPEC results, and end user expectations, 
> all of which are dear to my heart.

What do you think?   My belief is that most end users, most of the time,
just want to make their existing programs run faster UNCHANGED.   That includes
makefiles and shell scripts, which are programs too.