Author: Vincent Diepeveen
Date: 10:25:25 01/01/02
Go up one level in this thread
On January 01, 2002 at 13:12:40, Heiner Marxen wrote:
>On January 01, 2002 at 07:44:31, Vincent Diepeveen wrote:
>
>>On December 31, 2001 at 16:07:43, Scott Gasch wrote:
>>
>>>On December 31, 2001 at 16:03:36, Scott Gasch wrote:
>>>
>>>>On December 31, 2001 at 15:57:28, Bruce Moreland wrote:
>>>>
>>>>>
>>>>>How many elements are in "iRanks"? If the answer is 8, there is your bug.
>>>>>
>>>>>In Pascal, arrays are usually 1..N. In C, they are typically 0..N-1. Your
>>>>>asserts indicate that you may be thinking in Pascal.
>>>>>
>>>>>I have more ideas once you indicate that there are more than 8 things in that
>>>>>array.
>>>>>
>>>>
>>>>typedef struct _PAWN_HASH_ENTRY
>>>>{
>>>>INT64 i64Sig;
>>>> short iWhiteValue;
>>>> short iBlackValue;
>>>> unsigned char iFiles[2][10];
>>>> unsigned char iRanks[2][10];
>>>> unsigned char iPawnsOnWhiteSquares[2];
>>>> unsigned char iUnmovedPawns[2];
>>>> unsigned char iRammedPawns[2];
>>>> unsigned char iBackwardPawns[2];
>>>> unsigned char cPassed[2][10];
>>>> unsigned char iPasserInfo[2][10];
>>>> unsigned char iPassedCount[2];
>>>>#ifdef PARANOID
>>>> POSITION pos;
>>>>#endif
>>>>} PAWN_HASH_ENTRY;
>>>
>>>Darnit, I have a bad habit of submitting early by pressing [tab][space] by
>>>accident when typing code.
>>>
>>>iFiles and iRanks are arrays with 10 elements -- the 0th and 9th are phantom
>>>files so I don't have to check for "off the board" in my code. iFiles is the
>>>count of how many pawns are on that file and iRanks is the rank of the most
>>>advanced one. If there's no black pawn on a rank, iRanks[BLACK][file] is set to
>>>zero for passer detection. Likewise no white pawn on a rank means
>>>iRanks[WHITE][file] is set to 9.
>>>
>>>I'll all ears for other ideas. This is driving me nuts. It has to be some
>>>problem in my code but I sure don't see it. I've verified I'm not trashing
>>>anything on the stack by writing to a stack array out of bounds -- which might
>>>cause whatever address it's trying to load into esi just before the crash to be
>>>wrong.
>>>
>>>Thanks for the ideas.
>>>Scott
>>
>>Hi Scott, 8 bits code is usual faster than 32 bits of course,
>>but may audience know from you why you make all datastructure code 8 bits
>>here?
>>
>>Why not make it all 32 bits?
>
>Excuse me for jumping in...
>I suspect he wants to have lots of those PAWN_HASH_ENTRY objects, so it is
>a good thing to have them 1/4 as large, because now he can have more of them.
I guess he has only 1 pawn hash entry structure (not object).
also more 8 bits code gives more register stalls. gives more buggy
code, and what is more important. Bugs or using a few bytes more?
>
>Also, generally using more memory will cause more cache misses, and those
>cost many cycles. Sometimes the panelty is smaller than the gain, but
>sometimes not. I have sometimes had significant slowdowns because of using
>some more KB of data (happened to me with the random value arrays for the
>zobrist hash).
you talk k6 times here ?
L2 cache is like 512KB. not small. With DIEP i'm outside that anyway.
>
>Cheers,
>Heiner
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.