[Freeciv-Dev] Re: Unused field in move_cost_map removed.

[Gregory Berkolaiko <gberkolaiko@xxxxxxxxxxx>]

 --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote: 
> On Wed, Sep 19, 2001 at 12:13:37PM +0100, Gregory Berkolaiko wrote:
> >  --- Raimar Falke <hawk@xxxxxxxxxxxxxxxxxxxxxxx> wrote: 
> > > On Tue, Sep 18, 2001 at 01:51:21PM +0100, Gregory Berkolaiko wrote:
> > [..]
> > > 
> > > Thue confirmed that this was the original intention. Still the
> > > number I get from you aren't clear. How many times is this shortcut
> > > taken?

okay I run some simulations.  the percentage of getting already processed
tiles vary between 0 and 8 with average about 4 I would say.  the total
number varies hughely, but a typical example is:
2: generate_warmap: (1078, 0) tiles processed
2: generate_warmap: (140, 6) tiles processed
2: generate_warmap: (775, 0) tiles processed
2: generate_warmap: (140, 6) tiles processed
2: generate_warmap: (953, 0) tiles processed
2: generate_warmap: (140, 6) tiles processed
2: generate_warmap: (884, 0) tiles processed
2: generate_warmap: (140, 6) tiles processed 
2: generate_warmap: (960, 0) tiles processed
2: generate_warmap: (332, 16) tiles processed
2: generate_warmap: (712, 0) tiles processed
2: generate_warmap: (330, 14) tiles processed
2: generate_warmap: (1, 0) tiles processed
2: generate_warmap: (143, 9) tiles processed
2: generate_warmap: (812, 0) tiles processed    

where first number is total tiles processed and second is for double
processed.  when first number is big, it corresponds to the sea and on
sea you have no roads/rivers so no tiles are doubly processed.

btw really_generate_warmap accounts for 95% of all "doubly processed
tiles".

> > from run-times was quite convincing.  Instead, I will find the places
> > in the code where danger of returning the same tile twice still
exists
> > and minimize such danger.

the attached patch (no_double_processing.diff) ensures that even if a
location is returned for the second time, it is not processed.  as usual
the savegames from test runs are identical with the current code's. 
unfortunately the solution is CPU efficient but not very clean due to
varying usues of get_from_queue.  personally, I think just removing the
warmap.returned and not caring about locations processed twice sometimes
is the best option.

test runs seem to second my opinion (surprise!)
configuration:
 set randseed 42
 set seed 42
 create vasya
 set aifill 7
 set timeout -1
 set endyear 1800
 hard
 start 

results:
no patches
251.600u 0.260s 4:16.07 98.3% 0+0k 0+0io 558pf+0w

only no_double_processing.diff
251.600u 0.260s 4:16.07 98.3% 0+0k 0+0io 558pf+0w

only remove_returned.diff
245.660u 0.200s 4:06.30 99.8% 0+0k 0+0io 637pf+0w
247.280u 0.380s 4:12.03 98.2% 0+0k 0+0io 637pf+0w <- higher system load

both patches
246.110u 0.160s 4:07.46 99.5% 0+0k 0+0io 637pf+0w
246.710u 0.200s 4:07.50 99.7% 0+0k 0+0io 637pf+0w

not only it takes less code to ignore doubly returned locations, it is
also a little quicker!

I hope I convinced you now.

> > What exactly gives you constant user times?
> 
> I experimented a bit:
[..]
> To answer your question: don't change the workload.

Err, my question was not how you manage to get similar run times for the
same code in the same configuration, but rather what code were you using
(with/without what patch).  Never mind.

Best,
G.

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

no_double_processing.diff
Description: no_double_processing.diff

remove_returned.diff
Description: remove_returned.diff