Re: [Gnushogi-devel] Some remark on GNU Shogi

[Yann Dirson]

Thanks for these interesting insights.  I CC those to the ml to get
some kind of archival until I or someone else) starts to work on them.

On Tue, Mar 04, 2014 at 11:29:53AM +0100, H.G. Muller wrote:
> Hi Yann,
> 
> I added some more patches to the hgm branch in the hgm.nubati.net gnushogi
> repository:
> 
> * I restructured the InputCommand routine such that it can execute some
> commands while polling for input, without aborting the search, and used this
> to let it respond to XBoard's periodic updates polling with the requested
> search info.
> 
> * I implemented the XBoard 'memory' command to set the hash-table size
> interactively. (I hope this doesn't have any unforseen side effects. It
> seems to work, based on the memory footprint of the gnushogi process.)
> 
> Because I had to examine the code a bit to see how it handles the
> transposition table, I noticed some irregularities and inefficiencies:
> 
> * The option "-T <size>" to set the TT size does not seem to work, as
> InitMain() called later immediately starts overwriting ttblsize with a
> compile-time default. This might be just as well, as the code processing the
> -T option sets it to <size>, while the man page in the doc directory claims
> it would set it to 2^<size>.
> 
> * This man page is not installed with make-install, btw.
> 
> * The comment in gnushogi.h states that ttblsz should be #defined to a power
> of 2. Depending on the compiler flags NOTTABLE and SMALL_MEMORY it can get
> the value 100001, however.
> 
> * In another place it is set to MINTTABLE+1, while MINTTABLE can be #defined
> as (8000), which is also not a power 2.
> 
> * Some aspects pervading the code make it really slow. E.g. the use of
> 'short' integer data types is a really bad idea on i386 or x64
> architectures, except in places where they would have huge impact on memory
> requirement. (E.g. in the transposition-table entries.) Current CPUs no
> longer support 16-bit data types, and code that uses them would need
> explicit machine instructions to pack and unpack them every time they are
> used.
> 
> * calculation of the  hash index involves a modulo operation with ttblsize,
> which is a variable not known at compile time. So the compiler cannot
> exploit the fact that it is a power of two, and would have to do a real
> division for every TT probe. This is absurdly expensive. (Crafty, for
> instance, slows down by 30% do to a single division per node!) The whole
> idea of the power-of-2 requirement was that the modulo operation could be
> done by AND-ing with a mask variable.
> 
> Regards,
> H.G.