Code, algorithms, languages, construction...
-
Prima
- Posts: 328
- Joined: Tue Dec 14, 2010 6:12 am
Post
by Prima » Mon Feb 07, 2011 3:44 am
Jeremy Bernstein wrote:Prima wrote:gaard,Jeremy, Marcos Costalba etc,
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?
-
gaard
- Posts: 127
- Joined: Thu Jun 10, 2010 1:39 am
- Real Name: Martin Wyngaarden
- Location: Holland, Michigan
Post
by gaard » Mon Feb 07, 2011 4:25 am
Prima wrote:Jeremy Bernstein wrote:Prima wrote:gaard,Jeremy, Marcos Costalba etc,
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.
-
Prima
- Posts: 328
- Joined: Tue Dec 14, 2010 6:12 am
Post
by Prima » Mon Feb 07, 2011 4:30 am
gaard wrote:Prima wrote:Jeremy Bernstein wrote:Prima wrote:gaard,Jeremy, Marcos Costalba etc,
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.
Okay I get it now. Thanks gaard.
-
BB+
- Posts: 1484
- Joined: Thu Jun 10, 2010 4:26 am
Post
by BB+ » Mon Feb 07, 2011 9:54 am
These incorporate proper root node probing, Peter's other changes, the Marco changes, the Decembrist TT changes, and so on
Think it's not yet counting
tb_hits after splitpoints. Here are some possible fixes (gleaned from ComStock):
Line 1509:
Code: Select all
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));
}
Line 2590:
Code: Select all
splitPoint.nodes = 0;
splitPoint.tbhits = 0; // add this
Line 2639:
Code: Select all
// 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);
and in
thread.h line 66:
Code: Select all
// 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];
-
Jeremy Bernstein
- Site Admin
- Posts: 1226
- Joined: Wed Jun 09, 2010 7:49 am
- Real Name: Jeremy Bernstein
- Location: Berlin, Germany
-
Contact:
Post
by Jeremy Bernstein » Mon Feb 07, 2011 11:18 am
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...
-
Peter C
- Posts: 154
- Joined: Thu Jun 10, 2010 3:12 am
- Real Name: Peter C
Post
by Peter C » Mon Feb 07, 2011 6:00 pm
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
-
Jeremy Bernstein
- Site Admin
- Posts: 1226
- Joined: Wed Jun 09, 2010 7:49 am
- Real Name: Jeremy Bernstein
- Location: Berlin, Germany
-
Contact:
Post
by Jeremy Bernstein » Mon Feb 07, 2011 6:17 pm
Peter C wrote: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
-
Jeremy Bernstein
- Site Admin
- Posts: 1226
- Joined: Wed Jun 09, 2010 7:49 am
- Real Name: Jeremy Bernstein
- Location: Berlin, Germany
-
Contact:
Post
by Jeremy Bernstein » Tue Feb 08, 2011 1:37 pm
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.
Jeremy
-
Uly
- Posts: 838
- Joined: Thu Jun 10, 2010 5:33 am
Post
by Uly » Tue Feb 08, 2011 1:53 pm
What about the PA_G and PA_I builds?