Re: [Bug-gnubg] Bitfields

[Jim Segrave]

On Mon 25 Nov 2002 (04:27 +0100), W.Stroop wrote:
> Hi there :)
> 
> OEPS typo in C code fragment
> Here is the right version
> 
> Just a remark.
> While examining 'eval.c' , i saw that some structures, which are used in
> a.o.  'eval.c &  'rollout.c ', contain bitfields. IMO those  bitfields( if
> used extensivily) are slowing down the program  a lot . As an example i give
> the assembly output of the following ' C ' code fragment
> 
> struct {
> unsigned int a : 5;
> unsigned int b : 6;
> }tbf ;
> 
>  void testfunc () {
>  int a,b;
> /* initialise struct */
>  tbf.a = 24 ;
>  tbf.b = 25;
> /* extract into a & b  */
>  a = tbf.a ;
>  b = tbf.b ;
> }


While you are right in general, I don't think that the use of
bitfields in gnubg will have any significant effect on performance. 

1) All the bitfields are being used as single bit boolean variables.
   In practice, they are tested often and altered very rarely. Testing
   of a bitfield boolean (where you aren't using the result for
   anything but making branching decisions does not require shift and
   mask operations, but rather simply testing bits in an int. You get
   sequences like:

   if ( ! prc->fCubeful )
    ...

   compiling to:

   testb  $0x1,0x78(%ebx)
   jne    0x80791ad <RolloutGeneral+809>

2) I think you'll find that acccess to bit field variables is a
   microscopic portion of run time. Run time matters most during
   evaluations (which affects choosing moves, analysis and rollouts).
   Here the dominant factors are the multiple evaluations of positions
   each involving a large number of floating point evaluations. I seem
   to recall being told that there are about 2500 inputs in the neural
   net, each of which has to be weighted and summed, then the outputs 
   of the hidden nodes have to be run through a non-linear function 
   to get the neural net output for a position. These will completel
   dwarf any possible inefficiencies caused by using packed structures
   of bitfields.
   My guess is that you're looking in the right place to speed up
   execution - eval.c, but you need to run a profiler to see where the
   time goes and the calling counts. There is, I believe, a fair
   opportunity to speed up gnubg's evaluator, but it will come from
   looking carefully at reducing the number of separate loops run in 
   routines like GetHalfPoints, rather than in micro-optimisations 

-- 
Jim Segrave           address@hidden