[GRASS5] Coding optimizations

Hello,

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.

--
Brad Douglas <rez@touchofmadness.com>

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.

--
Glynn Clements <glynn@gclements.plus.com>

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.