Author: Heiner Marxen
Date: 12:25:46 01/01/02
Go up one level in this thread
On January 01, 2002 at 13:25:25, Vincent Diepeveen wrote:
>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).
Yes, I meant multiple objects, not multiple data types, of course.
>also more 8 bits code gives more register stalls.
I don't know about register stalls, nor do I care, since this is very
specific to the exact chip/implementation (it is not even an attribute
of the architecture).
Although I currently have an AMD K7, I do not concentrate on that hardware.
My code shall run well on any decent hardware, be it Intel, HPPA, Alpha or
whatever.
> gives more buggy
>code, and what is more important. Bugs or using a few bytes more?
I don't want to disappoint you, but I have never had any significant problems
with using differently sized integral types in C (char/short/int/long).
For me that is not something I try to avoid.
>>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 ?
Actually, that effect could be measured on multiple, different hardware.
Since I first did not understand, why my presumed speed up change actually
resulted in slower execution I tried it on P5, HPPA, R4400 and K7.
All showed this effect, albeit the amount of slowdown differed.
Sorry, I did not save those numbers, so I cannot cite them.
>L2 cache is like 512KB. not small. With DIEP i'm outside that anyway.
My code is small enough (apx 200 KB), but any program using a transposition
table (hash table) is definitely out of L2 cache quite often. Those TT
accesses does cause a lot of traffic between L2 and main memory, and also
replaces other unrelated data in L2 every once in a while.
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.