[Gdal-dev] Windows build from CVS

[Ed McNierney]

Frank -

Actually, internal optimizations in pow() are quite common, too, for 0, 1, and 2, although the conversions do of course occur.  I agree in making clear, readable code perform well and letting the compilers do their jobs.  I am not aware of ANY compiler on the market that would fail to the constant folding required here.

     - Ed

----- Original Message -----
From: Frank Warmerdam <warmerdam at pobox.com>
To: "Clay, Bruce" <bclay at ball.com>
Cc: gdal-dev <gdal-dev at remotesensing.org>
Sent: Fri,  8 Oct 2004 09:36:04 -0400
Subject: Re: [Gdal-dev] Windows build from CVS


> Clay, Bruce wrote:
> > This is one of those really trivial things but since some of the
> > operations in GDAL are performed millions or billions of times wouldn't
> > it make since to not perform redundant operations where possible.
> > 
> > Example: in the code shown below the operation 127 * 127 is performed 4
> > times X the number of times this method is called.  If the number was
> > changed to 16129 several cycles could be saved.  While it is true that
> > computers are getting faster and faster the databases are getting larger
> > as well.
>  >
>  >        M[M13] = byte[4] * fabs((double) byte[4]) * M[M11] / (127*127);
> 
> Bruce,
> 
> All but the most brain dead of modern optimizing compilers will compute
> constant expressions at compile time and the emitted code will have the
> resulting value.  I often like to leave expressions like the above in
> the code as it is easier to relate it to the original documented
> equations or in general to understand the meaning.
> 
> I think a more compelling case could be made that I should have optimized
> the fabs() call to just mask off the sign bit of the byte[4] which did not
> occur to me when I was writing the code.  Converting a signed byte to
> floating point and then invoking a floating point function just to clear
> the sign deep in per-pixel calculations is pretty pricey.
> 
> In this same source file I also used pow() to compute powers of two and the
> very general purpose pow() can be very expensive for something that should be
> achievable with left integer bit shifts.  However, a brief attempt to
> replace the pow() didn't work out, so I abandoned that effort.
> 
> I do try to be sensitive to performance issues but ultimately I only
> apply careful optimization in code that I feel will be heavily used or
> where a client has emphasized the importance of performance.
> 
> The good news is that AIRSAR images aren't getting any bigger.
> 
> Best regards,
> -- 
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
> 
> _______________________________________________
> Gdal-dev mailing list
> Gdal-dev at xserve.flids.com
> http://xserve.flids.com/mailman/listinfo/gdal-dev
>