Author: Peter Fendrich
Date: 12:32:22 11/12/04
Go up one level in this thread
On November 12, 2004 at 12:52:25, Mathieu Pagé wrote:
>On November 12, 2004 at 09:18:09, Peter Fendrich wrote:
>
>>Will C++ compilers (especially .NET) handle bit fields with decent performance?
>>It is very tempting to use them in hash tables for instance.
>>Something like this:
>>
>>struct Hash
>>{
>> unsigned KeyPart : 48; // 32+16
>> unsigned Eval : 16;
>> unsigned Flag : 2; // FH, FL, Inside
>> unsigned FrPiece : 4; // Move
>> unsigned Fr : 6; // Move
>> unsigned To : 6; // Move
>> unsigned Threat : 1;
>> unsigned Depth : 10;
>> unsigned Generation : 3;
>>} hash;
>>
>>hash.KeyPart = HashKey;
>>etc...
>>
>>/Peter
>
>Hi Peter,
>
>I did try this within my move class some times ago and unexpectedly I could not
>make it run as fast as an int from wich I mannualy (& and <<) parse.
>
>I said unexpectedly, because I don't see what is the problem and I did not look
>at the produced assembly code. I should have.
>
>I did test it with MSVC++ 2002.
>
>If you want to know for sure test it and let us know.
>
>Mathieu Pagé
Yes, I agree it shouldn't be so hard for the compiler.
But the internal order between the fields must be crucial because the compiler
isn't "allowed" to change that in order to optimise.
I will test and let you know but no assembly code reading here - it's not my
piece of cake!
BTW. The "unsigned KeyPart 48" is probably no good idea. I better use KeyPart1
32 + KeyPart2 16. I don't know what's happening with "uint64 KeyPart 48".
/Peter
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.