🚀 go-pugleaf

What machine are you running your tests on? Your nodes/sec
speed seem inordinately fast.

Mike McGann said:
$> 
$> PL68 vs PL69 - Is it slower?
$> 
$> You cannot directly compare the speed of PL68 and PL69. There are major differences
$> between them that make the comparison difficult.
$> 
$> PL68 generates legal moves and PL69 generates psuedo-legal moves. In raw speed as you can see
$> from the test position PL69 generates about 120k moves/sec and PL68 about 71k. PL68 was the first
$> version to use legal-moves all previous versions had used psuedo-legal moves. The general 
$> impression of most people was that the slower move generation was not offset by the gain from less 
$> moves to process. In individual positions this, of course could go either way. So in PL69 it was
$> back to psuedo-legal moves. Note also that evaluation is faster in PL69.
$> 
$> ******* PL69
$> 
$> White 0:00  Black 0:00
$> 
$>  R - - - - R K -
$>  P B Q P B - P P
$>  - - N - P - - -
$>  - - P N p P - -
$>  - - n - - - - -
$>  - - p b - n - -
$>  p p - - q p p p
$>  r - b r - - k -
$> 
$> Your move is? test
$> Testing MoveList Speed
$> Nodes= 820000 Nodes/sec= 192488
$> moves = 41
$> Testing CaptureList Speed
$> Nodes= 30000 Nodes/sec= 12096
$> moves = 1
$> Testing Eval Speed
$> Nodes= 15000 Nodes/sec= 2946
$> 
$> *******PL 68 
$> 
$> White 0:00  Black 0:00
$> 
$>  R - - - - R K -
$>  P B Q P B - P P
$>  - - N - P - - -
$>  - - P N p P - -
$>  - - n - - - - -
$>  - - p b - n - -
$>  p p - - q p p p
$>  r - b r - - k -
$> 
$> 
$> Your move is? test
$> Testing MoveList Speed
$> Nodes= 820000 Nodes/sec= 71057
$> moves=41
$> Testing CaptureList Speed
$> Nodes= 30000 Nodes/sec= 8695
$> moves=1
$> Testing Eval Speed
$> Nodes= 15000 Nodes/sec= 1827
$> 
$> 
$> **** SAVEHT
$> 
$> SAVEHT was a variable that is used to prevent caching of moves that used partial search in their evaluation.
$> Its use changed between PL68 and PL69. SAVEHT was introduced in PL68 to prevent the caching of moves whose
$> score contained values generated by capture only search as these were not true scores. In PL68 it is a binary
$> indicator. As soon as capture only search was invoked all caching stopped in that leg of the tree. In PL69
$> I attempted to gain back some of the information by changing it to say that the score from the capture only
$> would be used but the depth of the score would be the last full width depth. So up until capture only
$> search moves were cached with depth ply and below that depth SAVEHT. SAVEHT is also affected by QBLOCK.
$> 
$> To revert to the PL68 SAVEHT the correct patch is:
$> 
$> gnuchess.h
$> 
$> 	#define QBLOCK false
$> 
$> search.c 
$> 
$> 	if (flag.hash  && !SAVEHT /*&& ply <= Sdepth*/ && *rpt == 0 && best == alpha)	
$> 
$> 
$> 
$> I am continuing to look at the positions that were posted.
$> 
$> mike
$> mwm@ascom.ch
$> 
$>