gnugo-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gnugo-devel] A lot of questions


From: Gunnar Farnebäck
Subject: Re: [gnugo-devel] A lot of questions
Date: Thu, 18 Aug 2005 00:54:07 +0200
User-agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.9) MULE/5.0 (SAKAKI)

Lukasz Lew wrote:
> Complexity:
> - additional bool array
> - clearing the array in appropriate places (where? new position?)

Yes, new_position() should be the right place.

> - 8 places in the code updating the array illegal -> possibly legal 
>   (informal proof that no more is needed)
> - checking and updating the array in is_legal and trymove
> 
> Improvement in performance for my needs (MC playouts) is very large, but 
> for the code of Gnu go it would be much smaller.
> What degree of the speed improvement would be needed?

That depends on how much more code is needed.

> Are there any tools in the package measuring performance?

The best way is to replay games, e.g. by running the scripts in
regression/benchmark. E.g. under unix, from the regression directory,
running

time ../interface/gnugo --mode gtp < benchmark/GnuGo-Go4.gtp

would give a speed measurement. (Notice that for accurate measurements
there should be very little load on the machine and it should
absolutely not have any speed variations related to processor
temperature, as is common on laptops.)

> The main differences are:
>   - build in legality check in trymove with illegal suicide
>   - maintaining stack in trymove  vs  move_history + new_position in play_move

This is the big difference. The trymove stacks would need to be much bigger.

> The superko can be only checked after the move, so I propose
> adding an additional function to the boardlib : is_position_repeated.
> That would return a bool whether we entered into illegal cycle.
> 
> It would be implemented on a hash set and work for both trymove and 
> play_move. 

It's fairly straightforward to implement but I'm doubtful about having
it in trymove(). We have other mechanisms (komaster) to eliminate many
cycles, which is partially much more limiting than superko. Thus a
superko test might be a waste of time.

> I would like to again ask how could I help to solve the problem with 
> MAX_STRINGS and MAXSTACK 
> Is the segfault a known behaviour? 

I have to look into this a bit more, but preliminarily I would say it
has been encountered before. However, could you tell us how long games
your simulations lead to?

/Gunnar




reply via email to

[Prev in Thread] Current Thread [Next in Thread]