[Bf-committers] Code optimisation

john tuffen bf-committers@blender.org
Fri, 23 Apr 2004 10:24:31 +0100

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:

 float a,b,c,d;
 float x,y,z,w;

#define INLINE inline      /* for GCC - different for other compilers - should 
be defined via makefile probably! */

/* Vector add function */

vector_add(float *n, float *m, size)
 int i;
 for(i=0;i<size;++i) {

 float p[4];  /* holds a,b,c,d */
 float q[4];  /* holds x,y,z,w */


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 !!


7" single out now on iwari.com - namke communications: ice-9/salo
"... 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?