[Freeciv-Dev] Re: Map coordinate cleanups.

[Kevin Brown <kevin@xxxxxxxxxxxxxx>]

Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx> wrote:
> On Thu, 16 Aug 2001, Kevin Brown wrote:
> > Jason Dorje Short <jshort@xxxxxxxxxxxxx> wrote:
> > > I think any benefit players may get from extra speed is more than
> > > negated by the extra work developers have to do to use a macro for these
> > > functions.  Thus I agree that there is no _good_ reason to make it a
> > > macro.
> > > 
> > > In summary, I don't think these functions should be made macros. 
> > > Efficiency must be balanced with code cleanliness.
> > 
> > In any case, efficiency is often made up for by Moore's Law, while
> > code cleanliness isn't.  :-)
> 

[ the sequence of the following has been reversed for presentation
purposes.  :-) ]

> Function calls don't have a habbit of getting much faster.

I don't see how this would be the case, because it implies that the
operation of pushing arguments and current PC onto the stack and
jumping to the function location, then executing the function code,
then returning, doesn't get faster as CPUs and memory get faster.

Frankly, I don't believe it.  Access to the registers gets faster over
time.  Access to the caches get faster over time.  Access to main
memory gets faster over time.  The CPU clocks get faster over time
(which affects a lot of the other things).

There is NOTHING in a computer system that has remained the same speed
over the past 5 years aside from mundane things like keyboard
controllers.  EVERYTHING that counts here has gotten faster.

So what possible reason do you have for believing that function calls
haven't gotten faster over time???


> I suggest you delve a bit more in this problem. 

Okay, you asked for it!  :-)

I can PROVE that function calls have gotten faster.  Take the
following code:

#include <stdio.h>
#include <stdlib.h>

void func(void)
{
}

int main (int argc, char *argv[]) {
        int i, n;

        n = 1000000;
        if (argc > 1) 
                n = atoi(argv[1]);
        for (i = 0 ; i < n ; ++i) {
#ifdef CALLFUNC
                func();
#endif
        }
}


Now, let's establish the baseline time for execution of the code
without calling func():

[kevin@frobozz kevin]$ gcc -O -o /tmp/foo /tmp/foo.c
[kevin@frobozz kevin]$ time /tmp/foo 500000000
5.03user 0.01system 0:05.03elapsed 100%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (55major+6minor)pagefaults 0swaps

This was on my PPro 200 box.  Copy foo over to my Celeron 466 box and
run it:

[kevin@dimwit /tmp]$ scp -p frobozz:/tmp/foo .
foo                       |          3 KB |   3.8 kB/s | ETA: 00:00:00 | 100%

[kevin@dimwit /tmp]$ time ./foo 500000000
2.72user 0.01system 0:02.77elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (67major+8minor)pagefaults 0swaps



Now put in the function call:

[kevin@frobozz kevin]$ gcc -DCALLFUNC -O -o /tmp/foo /tmp/foo.c
[kevin@frobozz kevin]$ time /tmp/foo 500000000
18.42user 0.01system 0:18.74elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (55major+6minor)pagefaults 0swaps

and run it on the Celeron 466:

[kevin@dimwit /tmp]$ scp -p frobozz:/tmp/foo .
foo                       |          3 KB |   3.8 kB/s | ETA: 00:00:00 | 100%

[kevin@dimwit /tmp]$ time ./foo 500000000
9.81user 0.02system 0:10.10elapsed 97%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (67major+8minor)pagefaults 0swaps



So for 500,000,000 iterations on the PPro 200, the function call
itself takes 18.42 - 5.03 seconds, or 13.39 seconds.  On the Celeron,
the function call itself takes 9.81 - 2.72 seconds, or 7.09 seconds.

The Celeron is twice as fast.  Looks to *me* like function calls are
subject to Moore's Law...


> Besides, compilers can't optimize functions as well as inlined code.

Is this true of inlined functions?  I have suspicions that it is.  I'm
not sure how to devise a testcase for this...


The real question, of course, is just how much of a difference does it
really make?  It's worth putting something into a macro instead of a
function if it gives you an order of magnitude speedup for a
significant (30% or so) part of the execution of the program, but
anything less than that isn't even worth the hassle unless the use of
a macro instead of a function gives you other benefits (readability,
ease of comprehension, flexibility, etc.).  And keep in mind that the
macro has to be that much faster than an *inline* function, which
means that the optimizer has to make that much of a difference.  I'll
concede that this is possible, but I have trouble imagining that it
would happen often enough to make use of macros the preferred method
of improving performance.



-- 
Kevin Brown                                           kevin@xxxxxxxxxxxxxx

    It's really hard to define what "unexpected behavior" means when you're
                       talking about Windows.