[Bf-committers] Code optimisation

[john tuffen]

Well, I'll just add my thoughts on this. Yes, any half-decent compiler 
*should* recognise this sort of thing, but in my day job (embedded software 
progamming for microcontrollers - small/fast code really counts!) I have seen 
plenty of compilers that won't notice this sort of thing. As Bill says, it is 
often better to write simple-code that the compiler may recognise/optimise 
than to write code optimised for one platform (x86) which actually compiles 
worse for another platform (i.e. PowerPC)

 The only way to check whether a restructuring has been positive is to have 
the compiler generate assembler listings (with intermixed source) and actually 
check the generated code - for all supported platforms if possible(!)

 From a personal point of view:
 * variables shouldn't be called things like 'temp' either... give it a 
meaningful name, then others will be able to read the code more easily!
 * The array-of-floats idea is interesting but, seriously detracts from the 
readability of the code. It may be made more readable by using #defines and 
inline functions..., i.e. the previous example:

---------------------------
void
func(void)
{
 float a,b,c,d;
 float x,y,z,w;

 a+=x;
 b+=y;
 c+=z;
 d+=w;
}
---------------------------
becomes:
---------------------------
#define INLINE inline      /* for GCC - different for other compilers - should 
be defined via makefile probably! */

/* Vector add function */

INLINE void
vector_add(float *n, float *m, size)
{
 int i;
 for(i=0;i<size;++i) {
  a[i]+=x[i];
 }
}

void
func(void)
{
 float p[4];  /* holds a,b,c,d */
 float q[4];  /* holds x,y,z,w */

 vector_add(p,q,4);
}
------------------------------

Accessing of individual variables (such as a,b,c in the 'before' example) can 
be mimicked by using #defines (such as "#define a (p[0])") if individual 
access is required in a meaningful way.

But, as Ton says - if the code is the product on a single individual, then 
coding style may not want to change too much since then it may lose its 
maintainer !!


john..

--
7" single out now on iwari.com - namke communications: ice-9/salo
http://www.iwari.com/
http://www.minimism.com/
--
"... 2 tracks of lush deep 4/4 house." (BoomKat)
---------------



Quoting Bill Baxter <baxter@cs.unc.edu>:

> Yes, I believe that will be done automatically by any half-decent 
> compiler.  It's called common subexpression elimination CSE (or CSEE).  
> I think it's pretty much covered on day one of any advanced compilers 
> course.  It's pretty much the lowest hanging fruit there is when it 
> comes to code optimizations, next to removing name dependencies.
> 
> Besides, it's utterly pointless to optimize something like this until 
> you profile and find out it is actually a bottleneck.  As Amdahl's Law 
> tells us, if the code you optimize is only responsible for 0.1% of the 
> execution time, then even if you make that code infinitely fast, the 
> best you can do is speed up the program by 0.1%.  Finally, even if it 
> *is* really a bottleneck, then after you think you've optimized it you 
> better profile again to make sure it actually runs faster.  Often the 
> compiler will be smarter than you think since it might know about actual 
> register counts and other architectural details about the machine that 
> affect performance of code.  Sometimes "optimizations" can restrict the 
> compiler's freedom to allocate registers how it wants.
> 
> --bb
> 
> Kenneth Styrberg wrote:
> 
> > Hi, I did some optimisation in interface_draw.c. I havn't tested how 
> > much it improves performance, at least the code looks  a tiny winy bit 
> > cleaner. Maybe all compilers do this optimisation at compile time?