[Freeciv-Dev] Re: Map coordinate cleanups.

[Justin Moore <justin@xxxxxxxxxxx>]

> Its more than pushing arguments and PC onto the stack, you must save all
> the registers you are using too and the machine status word. Ands jumps
> are getting to be worse and worse. When you do many long jumps you are
> trashing the code cache and function calls usually are long jumps.

   This used to be the case, but it less and less a problem.  Sliding
registers and register renaming/aliasing are allowing for faster and
faster context switches.  And the trashing of the code cache depends on
how large the function is and how often it's called.  If's a relatively
small function it should fit nicely in the cache and access will not be
that bad.

> This is the reason jumps are bad:
> Regardless of what you may think main memory speed hasn't kept pace with
> cpu speed in the last decades. The gap between CPU and memory speed keeps
> increasing. There have been some sucessfull efforts in recent years in
> memory bandwith but latency is still poor. And besides it still isn't
> keeping pace with CPU speed. The CPU designers offset this with ever
> increasing cache sizes. It helps but it isn't perfect.

   ... and roughly every one in seven instructions is a jump of some sort.
I see you've taken the same kind of architecture classes I have. :) Even
with modern branch predictors attaining >96% accuracy you're going to have
a pipeline stall relatively frequently.  And with many of the macros
implementing multiple boolean tests sequentially, at *some* point the code
is going to be short-circuited around the remaining tests and all your
prefetching and caching goes to waste.

> Contrary to what you think access to the L1 caches doesn't improve
> compared to CPU speed in fact, recent L1 caches take more than the 1
> clock cycle they used to in order to get an access.

   LMbench of a few machines around indicates that even an L2 cache hit
will take about 2/3 of the time to read main memory, compared to the 2-3
cycles required of an L1 hit.  Bottom line: if you don't hit it in L1,
you're fukked one way or another.

> Sure. I didn't say that. What i say is that the rest of the systems keeps
> drifting more and more regarding the CPU in terms of speed. You remember
> the time when system buses used to be as fast as CPUs? Well now they
> aren't, and I/O keeps getting slower. As fast as a CPU may be it is
> limited by core memory and peripheral speed.

   Some BOTE calculations indicate that effective CPU performance is going
to be more and more dependent on branch predictors and not clock speed.
With increasing pipeline depths and a growing cache/CPU gap, the cost of a
context switch is going to become less and less "bad" compared to even a
simple string of conditional tests.  You still have to flush the pipeline
if you guess wrong.

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

   But what you're ignoring is the fact that compilers will get better,
even if main memory and cache access times aren't.  Gcc may not be C99
compliant now, but what about a year or two from now?

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

   A one line function may not be easily optimized, but that's not really
the focus of the debate (I think); code that potentially provide a layer
of abstraction or are multi-line functions should really become inlined
functions and let the compilers catch up.  And see above about context
saving and restoring.

> IMHO making one line functions that are used over and over again isn't a
> good idea. Unless you really *must* use a function.

   I think the point here is to decide what kind of stuff we *must* use
functions for. :)

-jdm

Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  justin@xxxxxxxxxxx