Author: rasjid chan
Date: 12:03:15 08/27/05
Go up one level in this thread
On August 27, 2005 at 10:16:03, Robert Hyatt wrote:
>On August 27, 2005 at 01:42:32, rasjid chan wrote:
>
>>I am making basic changes to snailchess and have a set of things that I am
>>not certain and welcomes any help.
>>I use 0x88 squares.
>>
>>1) I dislike using large memory arrays thinking modern cpu are better in
>>computing with registers than memory read/write and so this may be critical
>>for nps. Is this actually outdated?
>>(related - Uri mentioned many times he plans to use less global variables - just
>>like in Fruit?)
>>2) Related to the above, I have this:-
>>
>> char pst_pawn[64] = {};
>> char flip[64] = {};
>>
>> I don't like char/int pst[128] because some say it swaps away many things from
>> critical cache.
>
>You are wasting your time and this is probably more expensive than just making
>the thing 128 bytes long. On intel, cache lines are 128 bytes long anyway, so
>you will _never_ be able to read less than 128 bytes from memory. On AMD cache
>lines are 64. Keep it simple.
>
>most caches are at least 512K and many are now 1024K. Don't worry about the
>above, since you use that data frequently anyway.
I am ignorant about microprocessors and never think about 512k - I now think
it is quite alot == 4026 x 128bytes!
> The hash table hurts cache
>way more than that does...
I do have suspicion that here may matters a lot and I am just paying attention
to this now.
>>
>> if (white)
>> score = pst_pawn[sq88To64(sq)];
>> else
>> score = pst_pawn[flip[sq88To64(sq)]];
>>
>> I can't get a macro substitution for flip[64] - excuse my IQ.
>>3) I have a max rank/file distance macro here, the best I can manage is:-
>>
>> #define max_rf_distance(x, y) max((x)-((y)&0xf0)&128? (y)-((x)&0xf0)>>4\
>> : (x)-((y)&0xf0) >>4, (x)-(y)&8? (y)-(x)&7:(x)-(y)&7)
>>
>> Is there a better trick for this?
>>
>>4) retrieving the PV.
>> This was discussed over at the winboard forum but I am still not too clear.
>> We have :-
>> a) the pv[ply][ply] method. But hash probe returns on exact usually make
>> the PV short. Is this superflous when there is hashing?
>> b) "retrieving" by the hash table method.
>> There was concern about the entries being overwritten but Vincent
>> Diepeeven said "there is a one-to-million chance.. " and he mentioned the
>> replacement scheme (probably crucial) of his but not too easy to
>> understand.
>>
>
>That is all irrelevant. The problem is this: When searching the PV, and you
>first get to node X, you search some depth D below that point. That is your PV,
>and the best move stored at node X during _that_ search is the PV move. But
>after you have searched node X, and backed up to an earlier point in the tree
>and continue searching, you can again reach position X, but at a deeper or
>shallower level in the tree. And you can overwrite it easily. This time around
>you might be failing low, and you store no best move. When you come back later
>to reconstruct the PV from the hash stuff, you have no "best move"... Or you
>have a best move stored from the wrong depth. Etc. You either accept that, or
>do as I do and just back up the PV. The overhead to back the PV up is
>essentially zero, because with PVS, it is very rare to search anything but v,v+1
>windows, and there is never a case to back up a PV in such positions...
Over at winboard, I had the impression that others have exceptional methods.
So I guess backing up PV is the way, cost should not be a factor.
Best Regards
Rasjid
>
>
>
>> What I understand about "retrieving" means do nothing, ie in any
>> iteration, the PV is there as the bestmove from hash.
>
>IF it is there, and IF it wasn't overwritten by a shallower search.
>
>
>>
>> Or does "retrieving" mean something else specifically needed to be
>> done? (I am aware of IID)
>
>IID is yet another way to zap hash entries with the wrong move...
>
>
>
>>
>>Best Regards
>>Rasjid Chan
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.