[Freeciv-Dev] Re: goto cleanup

[Thue Janus Kristensen <thue@xxxxxxx>]

On Wed, 24 May 2000, Falk Hueffner wrote:
> Thue Janus Kristensen <thue@xxxxxxx> writes:
> 
> > On Tue, 23 May 2000, Falk Hueffner wrote:
> > > I wonder if it wouldn't be easier to simply add a small constant to
> > > the move costs on every move (with maxMoves * constant < 1). That
> > > would also have the nice effect that for costwise equivalent paths, it
> > > would choose the one with the least number of moves. This could be
> > > implemented either with floats or by pre-shifting the move costs by,
> > > say, 16 and using 1 as constant.
> >
> > Yes, that would actually be a nice simple solution. 16 would be a
> > bit much since the warmap use chars for movecosts and therefore have
> > a maximum of 255. (it would be nice for GOTOs to be longer than 20
> > tiles max...) We could use a smaller constant or change the warmap
> > to use shorts. Since changing to shorts in the case of a maximally
> > sized 200x100 map would only take 20KB I propose we do that.
> 
> I would even suggest to take ints or floats, since they're faster.
> Floats seem easiest, no need to scale the movement costs before adding
> the constant[1].

But they would consume more cache memory. I think it is
benchmark time... What shall it be? shorts, ints or floats? Would floats
be preferable because they didn't take up integer registers?
I don't think the scale argument for floats holds. If we use shorts we
would store them in an int for the use in the function, and compare then
to the maxcost on the warmap before adding them back in. No problem with
overflow here. And int are just to big to overflow for the things we use
them for.
Besides there must be a performance hit for using floats. And I know at
least one guy who plays freeciv on ARM, which have no FPU :).

> There's only ever one warmap, right? so it doesn't
> really matter with regard to memory.

Correct

> > I guess this will also remove some calculation in dir_ok(), also
> > nice!
> 
> I'm not sure if there's any need for dir_ok() ar all with this
> method...

Correct.

> > Will you make an updated patch or shall I?
> 
> Uhm, you're more into the code I think... If you don't get around, I
> could do it, though.

I may do it, but I would like to have the current patch into CVS first.

> A disadvantage, btw, is that the AI will have less paths for
> evaluation. I don't know what it acutally does with the set of
> optimal paths, seems it optimizes for least unit stacking or
> something. That mechanism would suffer. I still think it would be
> worth it (and it would allow a 100% optimal solution to be found much
> easier).

Yes, I also think it would be worth it. Though I am not entirely happy
about it...

>       Falk
> 
> 
> [1] Folks without FPUs please raise your hands, since currently I
> assume you don't really exist.

They do exist, as I said... :)

-Thue