optimizers

[Walter Bright]

In article <150 at ghostwheel.UUCP> ned at ghostwheel.aca.mcc.com.UUCP (Ned Nowotny) writes:
|  ...  Just because a compiler
| can be made smart enough to move a loop invariant out of a loop does not
| mean that it is a good idea.  It makes more sense to just provide the
| programmer with a warning.  If the code is incorrect, the programmer
| learns something valuable...

It's true, most optimizations performed by flow-analysis optimizers can
be done in the source code. The reasons for having the optimizer are:

o	The goals of optimized code and clear, maintainable code are
	usually not the same. I've spent a lot of time taking clear code
	and converting it into code that would win the obfuscated C code
	contest in the name of optimization. The optimization goal
	succeeded (up to 3 * faster), but the resulting code looked horrible.
	So I frequently put in:
		#if 1
			/* optimized version	*/
		#else
			/* original code left as documentation for above */
		#endif
	for critical routines that need the speed.

o	Note the above 'spent a lot of time'. My time is more valuable
	than machine time is. Even going through the code and experimenting
	with which variables should be 'register' is time I'd rather
	spend on my algorithms.

o	The results of tuning a program are not portable (the code will
	still work, but optimization for one machine may be unoptimization
	for another). An example would be the varying number of address,
	data and general purpose registers, and the varying styles of
	addressing modes available.

o	Only a small percentage of programmers understand the compiler
	and the underlying hardware well enough to wring the max
	performance out of a routine.

o	C is frequently machine-generated. It is best to use a straight-forward
	C-generation algorithm and let the C optimizer 'fix' it. This
	is the approach I've taken in my C++ compiler, and it works well.

o	Mopar rules.