Re: Speedy compilers (G-Man)
19 Dec 1998 11:21:23 -0500

          From comp.compilers

Related articles
[12 earlier articles]
Re: Speedy compilers (1998-12-18)
Re: Speedy compilers (1998-12-18)
Re: Speedy compilers (1998-12-18)
Re: Speedy compilers (1998-12-18)
Re: Speedy compilers (Jeff Jackson) (1998-12-18)
Re: Speedy compilers (1998-12-19)
Re: Speedy compilers (1998-12-19)
Re: Speedy compilers (1998-12-19)
Re: Speedy compilers (1998-12-19)
Re: Speedy compilers (1998-12-19)
Re: Speedy compilers (1998-12-19)
| List of all articles for this month |

From: (G-Man)
Newsgroups: comp.compilers
Date: 19 Dec 1998 11:21:23 -0500
Organization: Compilers Central
References: 98-11-047 98-11-086 98-11-089 98-12-040
Keywords: optimize, practice

Not all optimizers are created equal... the Cray Research (and now the
SGI compilers for supercomputers, essentially the compilers developed
by Cray Research) all default to full optimization. After all, why do
you have a supercomputer if you don't want to run fast?

It's really a matter of testing. If the default is optimization off,
that's what will be the most used, and it follows that it will also be
the most stable. With a default of full optimization, Cray/SGI
high-end compilers are if anything more stable with full optimization
than without it.

I've always been nervous about development strategies that build,
test, and debug with optimization off, then compile once with full
optimization and release the product... and expect it to work.
Unfortunately, this appears to be the dominant product development
strategy today. I feel very strongly you need to develop with the
exact configuration - including compiler optimization options - that
you intend to release with. If you don't, you've greatly degraded the
results of any testing done during the development phase.

On a related thread, the ex-Cray compilers perform some optimizations
even with optimization 'disabled'. For example, Fortran 90 array
syntax is vectorized - in a somewhat degraded manner - with
optimization disabled. Of course, with full optimization a much
better job is done. With the T3D/T3E compilers, a limited form of
common subexpression elimination is performed with optimization
disabled, as it not only improves performance, but helps compilation
speed as well by reducing the number of operations that need to be

-- Terry Greyzck (Rudi Ziegaus) wrote:
>[ re how much people care about compile speed vs. runtime speed ]
>There is a golden rule to code optimization, that I like to cite :
>"Never use it". I was working with MSC 5 several years ago when I ran
>into a problem with a so-called safe optimization. There were three
>optimizations built into the compiler that were regarded so safe that
>you didn't have to turn them on, but they were on by default and your
>only choice was to turn them off alltogether.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.