thanks for the patch builds. What version of Preserve Analysis (F - J ?) is this latest patch from Marcos Costalba based on?
It's Stockfish 2.0.1 + the Stockfish team's own code for PA on top of it.
Thanks for the reply Jeremy. I know the patch is from SF team (through Marcos Costalba) but what version of PA is this patch applied to? Currently, version PA_G is considered safe and stable.
Was this latest patch from the SF team (Marcos Costalba) applied to Stockfish 2.01PA_F/G, H, I, or J?
thanks for the patch builds. What version of Preserve Analysis (F - J ?) is this latest patch from Marcos Costalba based on?
It's Stockfish 2.0.1 + the Stockfish team's own code for PA on top of it.
Thanks for the reply Jeremy. I know the patch is from SF team (through Marcos Costalba) but what version of PA is this patch applied to? Currently, version PA_G is considered safe and stable.
Was this latest patch from the SF team (Marcos Costalba) applied to Stockfish 2.01PA_F/G, H, I, or J?
The patch is applied to the original source code for 2.0.1. It only includes the latest patch suggested by mcostalba. It does what versions G did and it's probably more thoroughly tested if it is going to be part of the next Stockfish release, therefore, I suggest using pamc or pamc with the addition changes by other forum members.
thanks for the patch builds. What version of Preserve Analysis (F - J ?) is this latest patch from Marcos Costalba based on?
It's Stockfish 2.0.1 + the Stockfish team's own code for PA on top of it.
Thanks for the reply Jeremy. I know the patch is from SF team (through Marcos Costalba) but what version of PA is this patch applied to? Currently, version PA_G is considered safe and stable.
Was this latest patch from the SF team (Marcos Costalba) applied to Stockfish 2.01PA_F/G, H, I, or J?
The patch is applied to the original source code for 2.0.1. It only includes the latest patch suggested by mcostalba. It does what versions G did and it's probably more thoroughly tested if it is going to be part of the next Stockfish release, therefore, I suggest using pamc or pamc with the addition changes by other forum members.
if (SpNode)
{
// Here we have the lock still grabbed
sp->slaves[threadID] = 0;
sp->nodes += pos.nodes_searched();
sp->tbhits += pos.tb_hits (); // add this
lock_release(&(sp->lock));
}
// We have returned from the idle loop, which means that all threads are
// finished. Update alpha and bestValue, and return.
lock_grab(&mpLock);
*alpha = splitPoint.alpha;
*bestValue = splitPoint.bestValue;
masterThread.activeSplitPoints--;
masterThread.splitPoint = splitPoint.parent;
pos.set_nodes_searched(pos.nodes_searched() + splitPoint.nodes);
pos.set_tb_hits (pos.tb_hits () + splitPoint.tbhits); // add this
lock_release(&mpLock);
// Shared data
Lock lock;
volatile int64_t nodes;
volatile int64_t tbhits; // add this
volatile Value alpha;
volatile Value bestValue;
volatile int moveCount;
volatile bool betaCutoff;
volatile int slaves[MAX_THREADS];
Thanks. Fixes incorporated. I moved a few things around and I'm pretty confident that it's working properly now. My only concern now is the use of hard probing at the root. If we don't, root values will be missed under low time conditions. However, it certainly adds some overhead. Any thoughts about that? I'll post new builds when I get off my train...
Jeremy Bernstein wrote:Thanks. Fixes incorporated. I moved a few things around and I'm pretty confident that it's working properly now. My only concern now is the use of hard probing at the root. If we don't, root values will be missed under low time conditions. However, it certainly adds some overhead. Any thoughts about that? I'll post new builds when I get off my train...
I think we shouldn't hard probe at root. The positions where that would matter are less important than the speed we would lose.
Jeremy Bernstein wrote:Thanks. Fixes incorporated. I moved a few things around and I'm pretty confident that it's working properly now. My only concern now is the use of hard probing at the root. If we don't, root values will be missed under low time conditions. However, it certainly adds some overhead. Any thoughts about that? I'll post new builds when I get off my train...
I think we shouldn't hard probe at root. The positions where that would matter are less important than the speed we would lose.
Peter
We should do some testing first, to see if there is any practical speed loss. I've demonstrated already that there are very practical situations in which Stockfish can lose on the basis of missed tb values. And that was just one random game.
Another question: is there any point to adding the root tb probe return value to the hash? Any hit found will end the search, anyway. Jb
I feel like the MC settings for PA are slightly disadvantageous for the engine. I'm running a 3/1 tournament right now. Results so far:
Engine Score St St St St St S-B
Stockfish-201-64-ja 30,5/52 ·············· =1==101=1=10= =0=10====1=11 11==1010=0=== 1==1=11=0==== 775,00
Stockfish_201_x64 28,5/53 =0==010=0=01= ·············· ==1=0=01====== ==========1=1 =====1=11=11= 722,75
Stockfish_201_64_pamc 25,0/53 =1=01====0=00 ==0=1=10====== ·············· =10=0=1==1==0 ==0=1=0=0==1= 667,50
Stockfish_201_popcnt_pamc 24,5/53 00==0101=1=== ==========0=0 =01=1=0==0==1 ·············· =1=0=1=00===== 655,00
Stockfish_201_PAMC_GTB_x64 23,5/53 0==0=00=1==== =====0=00=00= ==1=0=1=1==0= =0=1=0=11===== ·············· 625,25
132 of 500 games played
Level: Blitz 3/1
Hardware: Intel(R) Xeon(R) CPU W3520 @ 2.67GHz 2659 MHz with 1,0 GB Memory
Operating system: Windows 7 Professional Professional (Build 7600) 64 bit
201_x64 is my compile of the standard stockfish code, 64_pamc and popcnt_pamc are gaard's builds, PAMC_GTB_x64 is my build with tablebases. There aren't enough games to draw any real conclusions yet, but standard stockfish seems to slightly outplay the pa builds.