[GRASS5] Coding optimizations

Michael Tiemann tiemann at redhat.com
Tue Feb 15 09:37:14 EST 2005


As a person who worked on the GNU C compiler from 1987-1997, I can
wholeheartedly support the notion that you don't want to waste your time
writing multiplication as a (series of) shift(s) (and adds).  Any
competent compiler these days has complete visibility into the
mathematical equivalence of *2 and <<1 (and a variety of other
equivalences).  Moreover, with super-scalar processors, the compiler
probably knows more about whether the shifter, the multiplier, or the
adder unit is free at what time to create the most efficient use of
processor resources for a given expression.  Even stuff that /looks/
worse to you has, if you are working with a half-decent compiler, been
tuned to clock faster on the chip.  I spent years doing these
measurements, and I know my successors are doing an even better job than
I ever did.

The /only/ time you want to obfuscate arithmetic code for performance
reasons is when you have measured a /specific/ function being
specifically performance-critical, and when you know precisely how the
obfuscation is going to be compiled by the compiler.  And in that case,
you might decide to venture into assembly code.

That said, don't expect a compiler to rewrite your algorithms to take
you from O(N^4) to O(log N), or to reorganize data structures so you
don't thrash the cache.  But if your compiler can't do math, get one
that can.  The GNU compilers are free, and target more processors on the
planet than any other (from 8-bit to 128-bit), so there's no excuse.

M

On Tue, 2005-02-15 at 07:53, Glynn Clements wrote:
> Brad Douglas wrote:
> 
> > I have a question regarding coding policy.  Is it acceptable to add
> > basic optimizations such as bit shifting for exponential
> > multiplication/division and hard-coding values like sqrt(2.) to an
> > arbitrary precision?
> > 
> > Generally, these are things the compiler should be capable of, but is
> > sometimes not the case.
> 
> In normal algebraic expressions, I would write x*2 rather than x<<1 on
> the grounds of legibility. I would only use bit-shifting if it more
> accurately reflected the nature of the code, not as an optimisation.
> 
> OTOH, I would normally define sqrt(2.) as a constant. Writing SQRT2
> isn't really any less legible than sqrt(2.), might be substantially
> more efficient (particularly if the architecture doesn't have a
> square-root instruction), and doesn't require linking against the math
> library.




More information about the grass-dev mailing list