Code efficiency

[Kevin Buettner]

On Feb 7,  2:04pm, sinck@corp.quepasa.com wrote:

> I was chatting with my carpool buddy on the way home (suprise), and he
> stated that coding something along the lines of
>
>     while (--i > 0)
>       {
> 	  p++;
>       }
> 
> would be faster than a classic
> 
>     for (i = 0; i < 50; i++)
>       {
> 	  p++;
>       }
> 
> based on the predecrement already setting the zero flags in the
> appropriate registers and involving fewer instructions.
> 
> Well, I thought to myself, self, "I don't believe that it would make a
> bit of difference using modern compilers."  Furthermore, myself went
> on: "I bet gcc -O2 and stripping make more difference in the size."  So
> I set out with the following .c file:

The only problem that I have with this is that looking at the size of
the object file is not going to tell you very much about performance.

As John Gorman pointed out, you'll learn more about the different
coding techniques if you look at the assembly output via -S.  You'll
learn even more about which is more efficient by benchmarking all
three programs.  Note that the results may differ depending on the
architecture.

Also, if your compiler is really agressive and p is not used in any
computations after the loop, the compiler can safely remove the
increment of p.  In fact, it could remove the entire loop!  Or, if p
is used, it could precompute p based on the fact that your loop has a
constant number of iterations.

When I write tests like this, I usually put in some function calls
(which don't have to do anything) like so...

    
    for (i = 0; i < 50; i++)
      {
	  p++;
	  f(p);
      }

    ...

    void f(int i)
    {
    }

So long as the compiler in question does not contain a global optimizer
and automatically inline f() on me, adding the above function call
will cause the loop to be generated.  If the compiler does contain
a global optimizer, moving the definition to another object file
should be enough to foil it.

> My moral would be thus: code for supportability and leave the magic to
> the compiler.

I agree.  Just code in a straightforward, reasonably efficient manner,
and let the compiler worry about the low level optimizations.

Kevin

-- 
Kevin Buettner
kev@primenet.com, kevinb@redhat.com