Author: Robert Hyatt
Date: 14:49:11 11/15/02
Go up one level in this thread
On November 15, 2002 at 15:16:54, Dieter Buerssner wrote:
>On November 14, 2002 at 17:16:26, Robert Hyatt wrote:
>
>>On November 14, 2002 at 13:35:25, Dieter Buerssner wrote:
>>
>>>On November 13, 2002 at 15:55:51, Robert Hyatt wrote:
>>>
>>>
>>>>You can do that in C with bit-fields as well, but it both it and ADA are
>>>>horribly
>>>>slow when you fiddle with bitfields.
>>>
>>>Can you show a small example, where bit-fields in C produce horribly slow code?
>>>I am aware of the fact, that much of the internal data layout of bitfields is
>>>implementation defined in C, so, as in many other cases too, some low level
>>>tricks (for example by using unions) cannot be coded portable. But the same is
>>>already true without using bit-fields. However, assembly output I looked at,
>>>seemed very reasonable. There are some pitfalls, like type int may be signed or
>>>unsigned int, but this can be taken care of in the code, by never using int
>>>alone without signed or unsigned.
>>>
>>>Regards,
>>>Dieter
>>
>>
>>The first place I found it was in my compressed move format.
>>
>>IE I had a move defined as
>>
>>struct move {
>> unsigned int from:6;
>> unsigned int to:6;
>> unsigned int piece:3;
>> unsigned int captured:3;
>> unsigned int promot:3;
>>}
>>
>>I noticed how slow it was by simply packing/unpacking directly in C using AND/OR
>>bitwise operations, and it sped it way up. I tested this on two compilers of
>>the time,
>>gcc and sun's CC compiler...
>
>Can you give a code snippet, that shows the "horribly slow" preformance?
>Actually, I used a similar move struct long ago. My reason to switch to unsigned
>long was, to be able to portably make a more compressed format. With only from,
>to and promote, I can easily reconstruct the total move structure. These fields
>will fit in an unsigned short, and save some space (for example in the
>transposition table). So, by some manual tuned arrangement of the fields in an
>unsigned long, I can do move&0x7fff, and get all I need. This would not be
>possible with bit-fields in a protable way (because the C-Standard says nothing
>about the internal data layout). Other than this, all assembler code I checked,
>was practically identical with using bit-fields, and using the manual
>shifting/masking.
>
>BTW. You will remember all your discussions with Vincent about Intel CC bugs.
>Vincent failed to give a concrete example, so you could not get convinced. The
>same here. You will see the similarity :-)
>
>Regards,
>Dieter
I don't have a snippet as the old versions of Crafty were lost several years
ago. But just filling in the from/to/etc fields was slow compared to the
shift/or approach I use today.
Another bad problem is that bit-fields were poorly thought out by the ANSI
committee (as were many things poorly thought out). There is no specification
for which end of the word they start from, which is a problem...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.