Author: Robert Hyatt
Date: 07:16:03 08/27/05
Go up one level in this thread
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. The hash table hurts cache
way more than that does...
>
> 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...
> 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.