Author: Robert Hyatt
Date: 11:54:18 07/21/02
Go up one level in this thread
On July 21, 2002 at 01:29:38, Uri Blass wrote:
>On July 20, 2002 at 22:20:29, Robert Hyatt wrote:
>
>>On July 20, 2002 at 05:55:43, Uri Blass wrote:
>>
>>>On July 20, 2002 at 05:47:38, Gian-Carlo Pascutto wrote:
>>>
>>>>On July 20, 2002 at 02:52:11, Uri Blass wrote:
>>>>
>>>>>My question was not about comparing using hash tables
>>>>>and not using hash tables but about comparing using hash tables
>>>>>in the normal way and using hash tables
>>>>>for all purposes except pruning.
>>>>
>>>>In the example given, the move ordering from hashtable is almost
>>>>irrelevant, so all the gains are due to pruning.
>>>>
>>>>--
>>>>GCP
>>>
>>>I did not ask about single example from endgame but about
>>>the middle game or about rating improvement.
>>>
>>>Uri
>>
>>
>>I gave you an answer of sorts. Best case is fine 70. 3x as many plies.
>>Middlegame seems to be a factor of 2x in terms of time to reaching a specific
>>depth. So a fraction of a ply. So from early middlegame to endgame sees this
>>go from a fraction of a ply to (say) 30 additional plies...
>>
>>The 30 is important. It doesn't just happen in fine 70. It happens in lots
>>of important king and pawn endings.
>
>I know that in simple endgames you can get big improvement thanks to using hash
>tables for pruning.
>
>I also know that you can get a factor of 2 in the middle game from hash tables
>when the comparison is between using hash tables and not using them.
>
>It did not answer my questions.
>
>Only Christophe answered them when he explained that I may get 10% speed
>improvement in the middle game from pruning.
>
>Uri
OK... I will take my usual approach and simply give you _real_ data.
Three positions. The first tactical, the second just a middlegame position
with no real tactics, the last an endgame (fine70). All three searched with
normal hashing, and then using hashing as normal, but not allowing the hash
stuff to produce a fail high, fail low, or exact score. It can still tell me
to avoid a null-move search. The difference in times, then, is _totally_
dependent on using the hash scores only, as everything else is identical.
hashon hashoff
Tactical 48 secs 78 secs
normal 118 secs 183 secs
fine 70 0 secs 58 secs
In fine 70, both searched to 18 plies. hash on got right move (kb1
winning a pawn). hash off did not get right move.
You can draw your own conclusions. 10% is obviously _way_ too low. I
said roughly a factor of two, for middlegames, which is pretty close in
the first two. In the last position we _know_ what hashing does.
You can produce this by getting the crafty source, and finding the following
code in search.c:
switch (HashProbe(tree,ply,depth,wtm,&alpha,&beta,&mate_threat)) {
case EXACT:
if(alpha < beta) SavePV(tree,ply,alpha,1);
return(alpha);
case LOWER:
return(beta);
case UPPER:
return(alpha);
case AVOID_NULL_MOVE:
do_null=0;
}
Change it as follows:
int dum1, dum2; (put at top of search)
dum1=alpha; dum2=beta;
switch (HashProbe(tree,ply,depth,wtm,&dum1,&dum2,&mate_threat)) {
/*
case EXACT:
if(alpha < beta) SavePV(tree,ply,alpha,1);
return(alpha);
case LOWER:
return(beta);
case UPPER:
return(alpha);
*/
case AVOID_NULL_MOVE:
do_null=0;
}
This page took 0.01 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.