[Freeciv-Dev] Re: Map coordinate cleanups.

[Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx>]

On Fri, Aug 17, 2001 at 09:28:16PM -0700, Kevin Brown wrote:
> 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.

Ok this were enough technical arguments. Has anybody looked at the
numbers? You can't get profile data of method which just got turned
into a macro. But the calling time of calling method can be used to
measure improvements.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
  This customer comes into the computer store. "I'm looking for a mystery
  Adventure Game with lots of graphics. You know, something realy
  challenging". "Well," replied the clerk, "have you tried Windows 98 ?"