[Freeciv-Dev] Re: Map coordinate cleanups.

[Kevin Brown <kevin@xxxxxxxxxxxxxx>]

Vasco Alexandre Da Silva Costa <vasc@xxxxxxxxxxxxxx> wrote:
> On Fri, 17 Aug 2001, Kevin Brown wrote:

[...]

> > So what possible reason do you have for believing that function calls
> > haven't gotten faster over time???
> 
> They have gotten faster. But they don't get as fast as regular ops do. And
> this will be noticeable more and more as time passes. Unless someone
> invents an über-memory. But i doubt it.

Fair enough.  But it's not like what we're doing with Freeciv is
expanding to fill the capabilities of the machines we're running it on
or anything.  We're not *depending* on the hardware getting faster
just to be able to run reasonably.  Freeciv ain't no first-person
shooter.  :-)

> > The Celeron is twice as fast.  Looks to *me* like function calls are
> > subject to Moore's Law...
> 
> Bah. That program fits in the L1 cache. Freeciv doesn't even fit in the L2
> cache. That proves nothing. :)

Hehehe.  Okay.  But if the L1 cache speed isn't increasing at the same
rate that the CPU speed is increasing, then you'd think that the
numbers would show that.

Admittedly, it wasn't *that* good of a demonstration, since it only
covers perhaps 2 years of time, but it *did* prove my point: function
calls get faster over time, even if their improvement rate is slower
than for the rest of the CPU's functions.

> > > 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...
> 
> Inlined functions aren't part of the C89 spec. Sure they are part of the
> C99 spec, but how many 100% C99 compliant compilers do you know? (Hint:
> gcc isn't even one of them). Sure most C compilers have inlined functions
> in some form. But it isn't standard so they often use different keywords
> for it and so on. And remember the inline keyword is a hint. The compiler
> may ignore it.

Right.  But:

1.  As you say, most compilers have inlined functions.  That's all
    that's really needed here.  100% C99 compliance isn't.

2.  We have configure to detect what to do to declare an inline
    function.

3.  The compiler might ignore the inline keyword, but if it does so it
    might be because its optimizer thinks that the code will execute
    faster *without* inlining than with.  Don't know about this one,
    though.  I'd think that compilers which tend to do this would have
    an option to force the issue.

> > 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.
> 
> A one line function doesn't have much a compiler can optimize. If the code
> is inlined the compiler may do optimizations by using neighbouring code
> values and so on to speed things up. And you have no function call
> overhead. You could say this increases code size. I say that all the
> context saving and restoring and function call probably have more
> instruction than the function itself.

I'm not even arguing for substituting functions for one-line macros!
That would be silly: the macro is more concise in that case, so it
wins on most counts.  What's at issue here are the complicated macros
that would, IMO, be better expressed in a function, but which are made
macros for performance reasons.  For these, I'm of the opinion that
there's no substitute for testing.  If a function is a more
appropriate expression but there are concerns about performance then
the inline form of the function should be tested against the macro
form in the working code.  If the difference favors the macro
significantly enough then you go with the macro, else go with the
function.

There may be other reasons for using a function instead of a macro
(dealing with arguments that have side-effects comes to mind), but
those are separate issues.


It's really interesting, in participating in this list, to see how
people tend to assume the other person is taking the most extreme
position.  I just hope *I'm* not doing that!  :-)


-- 
Kevin Brown                                           kevin@xxxxxxxxxxxxxx

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