daveb@geac.UUCP (David Collier-Brown) (04/10/88)
In article <150@ghostwheel.UUCP> ned@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... Hmmn. I suspect that a source-to-source optimizer might be worthwhile, expecially one which would annotate the source with some of its assumptions while doing so. It probably need not be written to be time- or space-efficent: I'd take one written in prolong (oops! prolog). --dave -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
bright@Data-IO.COM (Walter Bright) (04/12/88)
In article <150@ghostwheel.UUCP> ned@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.