[Freeciv-Dev] Re: (PR#2370) Path finding

["Raimar Falke via RT" <rt@xxxxxxxxxxxxxx>]

On Sat, Nov 23, 2002 at 07:52:45AM -0800, Per I. Mathisen via RT wrote:
> 
> On Sat, 23 Nov 2002, Raimar Falke via RT wrote:
> > First: inlining. It is critical that this is done. Gregory uses macros
> ...
> > while I use the inline keyword. Both can provide the same results.
> 
> That Greg's version does not need to open the inline can of worms is a
> good thing. If we do add inline at a later time, his macros can always be
> turned into functions at that time.

I'm still for inline and I would like to restart the discussion.

> > Second: the speed depends strongly on the size of the node/cell. It is
> > currently about 20 bytes. It is possible to cache certain data but
> > this make the node/cell larger. I'm using defines:
> >
> > #define CACHE_TILE
> > #define CACHE_ECOT
> > #define CACHE_COP
> >
> > to control what is cached. However what should be cached depends on
> > how expensive the functions are (we can't tell this for ECOT) and how
> > this related to the memory system of the computer.
> 
> Figure out what is needed, and then remove those we don't use. Don't leave
> dead code in there.

Show me the average computer and the average user of PF and I will
find you this. As Gregory pointed out the final adjustment have to be
done after we some users.

> > So while currently caching the tile is good it may not if we inline the
> > map_get_tile function at some point.
> 
> I say we change get tile into a macro now, and check if we need tile
> caching afterwards. If we add inlining later, it can be changed from macro
> to inlined function then. map_get_tile() is, I believe, one of the
> functions we previously agreed we should macroify for performance, but
> nobody turned up with a patch for it.

Ack except s/change get tile into a macro/inline map_get_tile/.

> > Third: while not related to size of the node/cell it is similar to the
> > second point: use of a 1D array or use of a 2D array. I also have a
> > USE_2D define for this and _at my computer_ the 2D array is faster by
> > 4%.
> 
> 4% isn't much and doesn't warrant more complex code, unless there are
> other good reasons for it.

Other computers (SPARC for example may produce different results).

> > Fourth: how general/special do we want the queue implementation. If we
> > for example typedef that the queue works on shorts (16bit, less
> > memory) instead of void pointers or int we can get some speed. However
> > this makes the queue not general.
> 
> And what does this actually mean? What can't we do with the queue if it is
> typedefed to shorts instead of pointers?

All this matters only if we will have another user of this queue. This
user may for example want to store void * in the queue. Short would
fail here.

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 Q:  Do you know what the death rate around here is?
 A:  One per person.