[Top][All Lists]

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

Re: [Bug-gnubg] Bitfields

From: Jim Segrave
Subject: Re: [Bug-gnubg] Bitfields
Date: Mon, 25 Nov 2002 13:37:09 +0100
User-agent: Mutt/1.4i

On Mon 25 Nov 2002 (11:09 +0100), W.Stroop wrote:
> ----- Original Message ----- 
> From: "Jim Segrave" <address@hidden>
> To: "W.Stroop" <address@hidden>
> Cc: <address@hidden>
> Sent: Monday, November 25, 2002 8:18 AM
> Subject: Re: [Bug-gnubg] Bitfields
> [snip]
> > 1) All the bitfields are being used as single bit boolean variables.
> Well I dont think so 
> >From eval.h :
> typedef struct _evalcontext {
>     /* FIXME expand this... e.g. different settings for different position
>        classes */
>     unsigned int nSearchCandidates : 7;
>     unsigned int fCubeful : 1; /* cubeful evaluation */
>     unsigned int nPlies : 3;
>     unsigned int nReduced : 2; /* this will need to be expanded if we add
>       support for nReduced != 3 */
>     unsigned int fDeterministic : 1;
>     unsigned int fNoOnePlyPrune : 1;
>     float        rSearchTolerance;
>     float        rNoise; /* standard deviation */
> } evalcontext;
> As you see a 7 3 2 and 3 bit fields are also used.

Yes, you're right. I was thinking about rolloutcontexts (which I
recently did some work with). Nonetheless, changing these to separate
storage units, chars or whatever, is very unlikely, even with the less
than ideal code generation mingw seems to be giving, to make any
perceptible difference in performance for evaluating positions or
doing analysis or rollouts. The time saved will still be dwarfed by
the other code executed. 

Nonetheless, I would agree that non-single bit fields probably should
not be used unless space is *really* at a premium, which would not be
the case for evalcontexts. They simply don't buy you anything.

A better thing for Windows would be to find a gcc 3.x ported to
Windows, the code generator and optimiser on that version is a *lot*
better. From the sample code you gave, mingw is doing *horrible* code
generation (I think the bit test operators have been around since the
386). I don't know what the optimiser is like - certainly with gcc 2.9
and later, figuring out the assembler from the C can be challenging -
gcc is damned good at things like eliminating dead code, lifting out
loop constants and the like.

Jim Segrave           address@hidden

reply via email to

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