Looking at this position with Rybka 3 x64 on my quad
q3nrk1/4bppp/3p4/r3nPP1/4P2P/NpQ1B3/1P4B1/1K1R3R b - -
I kept running this analysis until Rybka x64 found Nc7. I would then close the entire application, repopen it and watch it's analysis.
Please excuse my ignorance but why wouldn't the engine evaluate the position the same way each time? Does learning have something to do with this? I was using Rybka 3 in the Deep Shredder 11 gui if that makes any difference.
I had it look at this a couple of days ago and it took it only 30+ seconds to find it. Today the first time took over 2 minutes?? My computer isn't busy with any other applications either.
11.00 0:01 +0.48 1...Ng4 2.Bb6 Ra6 3.Bd4 d5 4.f6 gxf6 5.Bh3 Bxa3 6.bxa3 Rxa3 7.Bxg4 Nd6 8.gxf6 Nxe4 9.Qb2 Ra2 (267.025) 144
12.01 0:06 +0.47 1...Ng4 2.Bb6 Ra6 3.Bd4 d5 4.Bf1 Ra5 5.Bh3 h5 (1.037.241) 160
13.01 0:07 +0.47 1...Ng4 2.Bb6 Ra6 3.Bd4 d5 4.Bf1 Ra5 5.Bh3 h5 (1.195.087) 160
13.16 0:12 +0.27++ 1...Nf6 (2.005.540) 169
13.01 0:14 +0.07++ 1...Nf6 (2.368.725) 171
13.01 0:26 -0.20 1...Nf6 2.Rd4 Nfg4 3.Bd2 (4.545.602) 172
14.01 0:35 -0.34 1...Nf6 2.Rd4 Nfg4 3.Bd2 Qa7 4.Rf1 Rb5 5.Bf4 Rbb8 6.Rb4 Rxb4 7.Qxb4 Rb8 8.Qc3 (6.090.976) 175
15.01 0:59 -0.43 1...Nf6 2.gxf6 Bxf6 3.Bc1 (10.576.536) 180
16.01 1:33 -0.49 1...Nf6 2.gxf6 Bxf6 3.Rd2 Rc8 4.Qxb3 Rb8 5.Bb6 Qc6 6.Rc1 Rc5 7.Rxc5 dxc5 8.Rc2 Rxb6 9.Qd5 Rb4 10.Qxc5 Rxb2+ 11.Rxb2 Qxc5 12.Rb8+ Qf8 13.Rxf8+ Kxf8 14.h5 Nd3 (16.726.013) 184
16.17 2:02 -0.63++ 1...Nc7 (22.748.618) 189
11.00 0:02 +0.59 1...Ra4 2.Rd4 Rxd4 3.Bxd4 (464.979) 210
12.01 0:02 +0.61 1...Ra4 2.Rd4 Rxd4 3.Bxd4 Qa4 4.Rh3 f6 5.gxf6 Bxf6 6.Bxe5 Bxe5 7.Qxb3+ Qxb3 8.Rxb3 g6 9.fxg6 hxg6 10.Nc4 (569.511) 207
13.01 0:04 +0.60 1...Ra4 2.Rd4 Rxd4 3.Bxd4 Qa4 4.Rh3 f6 5.Bxe5 dxe5 6.gxf6 Nxf6 7.Qxb3+ (908.005) 210
14.01 0:10 +0.71 1...Ra4 2.Rd4 Rxd4 3.Bxd4 Qa4 4.Rd1 h6 5.f6 gxf6 6.gxh6 Kh7 7.Bh3 Rg8 8.Bf5+ Kxh6 9.Be3+ Kg7 10.Rd4 Qc6 11.Qxc6 Nxc6 12.Rd3 (2.166.519) 206
14.02 0:20 +0.40++ 1...Ng4 (4.564.287) 224
14.01 0:41 +0.20++ 1...Ng4 (9.368.251) 230
14.01 1:01 +0.30 1...Ng4 2.Bb6 Ra6 3.Bd4 d5 4.Bf1 Ra5 5.Rg1 Nh2 6.Be2 Bxa3 7.bxa3 dxe4 8.f6 Rxa3 9.Bc5 Qa5 (13.754.480) 230
14.18 1:07 -0.20++ 1...Nc7 (15.355.117) 231
10.00 0:01 +0.54 1...Ra4 2.Qxb3 Nc7 3.Rd4 Ra6 4.Rc1 Nc6 (291.506) 201
11.00 0:02 +0.53 1...Ra4 2.Qxb3 Nc7 3.Rd4 Ra6 4.Qc3 Rc6 5.Qd2 Rb8 6.Rb4 Rc8 7.Rb3 Na6 (424.865) 206
12.01 0:03 +0.71 1...Ra4 2.Rd4 Rxd4 3.Bxd4 (785.730) 212
12.03 0:09 +0.36 1...Ng4 2.Bb6 Ra6 3.Bd4 d5 4.Bf1 Ra4 5.Rg1 Nh2 6.Bb5 dxe4 (2.023.829) 217
13.01 0:11 +0.44 1...Ng4 2.Bb6 Ra6 3.Bd4 d5 4.Bf1 Rc6 5.Qxb3 dxe4 6.Bb5 (2.378.348) 219
13.19 0:13 +0.16++ 1...Nc7 (2.998.114) 225
13.01 0:16 -0.04++ 1...Nc7 (3.745.752) 235
13.01 0:20 -0.44++ 1...Nc7 (4.906.614) 241
11.00 0:01 +0.45 1...Ra4 2.Qxb3 Nc7 3.Rd4 Ra6 4.Qc3 Rc6 5.Qd2 Rb8 6.Rb4 Rc8 7.Rb3 Na6 (193.889) 157
12.32 0:09 +0.46 1...Ra6 2.Bd4 Rc6 3.Qxb3 (1.588.918) 163
13.01 0:12 +0.46 1...Ra6 2.Bd4 Rc6 3.Qxb3 Nc7 4.Rc1 (2.022.078) 166
13.19 0:15 +0.26++ 1...Nc7 (2.540.285) 171
13.01 0:18 +0.06++ 1...Nc7 (3.273.197) 179
13.01 0:24 -0.34++ 1...Nc7 (4.400.916) 184
It's back to looking at Nf6 again?
10.00 0:01 +0.49 1...Ra6 2.Rd4 Ng4 3.Bg1 d5 4.e5 Nxe5 5.Bxd5 Qb8 6.Re4 Bxa3 7.Qxe5 Bd6 (231.436) 151
11.00 0:01 +0.49 1...Ra6 2.Rd4 Ng4 3.Bg1 d5 4.e5 Nxe5 5.Bxd5 Qb8 6.Re4 Bxa3 7.Qxe5 Bd6 (263.668) 151
12.01 0:02 +0.50 1...Ra6 2.Rd4 Ng4 3.Bg1 d5 4.e5 Nxe5 5.Bxd5 Qb8 6.Re4 Bxa3 7.Qxe5 Qxe5 8.Rxe5 Bd6 (454.094) 156
13.01 0:05 +0.59 1...Ra6 2.Bd4 Rc6 3.Qxb3 (931.234) 159
13.18 0:13 +0.30++ 1...Nf6 (2.143.975) 167
13.01 0:15 +0.10++ 1...Nf6 (2.606.086) 172
13.01 0:18 0.00 1...Nf6 2.gxf6 Bxf6 3.Rhg1 Rxa3 4.bxa3 Qxa3 5.Qa1 Nc4 6.e5 (3.121.734) 176
14.01 0:24 0.00 1...Nf6 2.gxf6 Bxf6 3.Bg5 Rc8 4.Qb4 (4.306.704) 179
14.19 0:28 -0.20++ 1...Nc7 (5.184.166) 183
14.01 0:30 -0.40++ 1...Nc7 (5.627.330) 186
14.01 0:43 -0.80++ 1...Nc7 (8.090.685) 190
Position Analysis - Same conclusions at different times?
Moderators: hgm, Dann Corbit, Harvey Williamson
-
Eelco de Groot
- Posts: 4557
- Joined: Sun Mar 12, 2006 2:40 am
- Full name:
Re: Position Analysis - Same conclusions at different times?
Hello John,
I think this is just caused by searching with more than one thread. I am assuming you don't have persistent hash enabled, because then Rybka would remember previous searches unless the Write Depth was too high to store anything.
Every chessprogram that can use more than one core will show this effect, it is not always so clear though. I'm no expert, but I think the operating system plays a role because it creates small differences in how much time each thread will spend on each core, the operating system has to balance the load between the four cores with all of the processes that are required to run the computer. At least that is how I understand it. If there is only a single core available for the chess program and all other tasks, then stopping the chess for a moment to do some other task makes no difference to the final result, it usually only means that same result, with the same nodecounts is achieved a little later or a little earlier each time. Each time the chessprogram is halted, it takes up exactly where it left off when it gets the processor back for itself. But if there are more threads used by your chessprogram, the switching causes tiny differences in what thread is looking at which positions at anyone time.
The threads interact with each other because they exchange information, mainly via the hash table. If one thread is now a little bit further with its work than another thread, compared with a previous try, the outcome is no longer exactly the same. You will have to average the results of many tries if you want an clear answer to how fast Rybka can solve the position. But this does not mean that at one time Rybka sees things better than at another time, it is just a matter of luck when the solution is found exactly.
Regards, Eelco
I think this is just caused by searching with more than one thread. I am assuming you don't have persistent hash enabled, because then Rybka would remember previous searches unless the Write Depth was too high to store anything.
Every chessprogram that can use more than one core will show this effect, it is not always so clear though. I'm no expert, but I think the operating system plays a role because it creates small differences in how much time each thread will spend on each core, the operating system has to balance the load between the four cores with all of the processes that are required to run the computer. At least that is how I understand it. If there is only a single core available for the chess program and all other tasks, then stopping the chess for a moment to do some other task makes no difference to the final result, it usually only means that same result, with the same nodecounts is achieved a little later or a little earlier each time. Each time the chessprogram is halted, it takes up exactly where it left off when it gets the processor back for itself. But if there are more threads used by your chessprogram, the switching causes tiny differences in what thread is looking at which positions at anyone time.
The threads interact with each other because they exchange information, mainly via the hash table. If one thread is now a little bit further with its work than another thread, compared with a previous try, the outcome is no longer exactly the same. You will have to average the results of many tries if you want an clear answer to how fast Rybka can solve the position. But this does not mean that at one time Rybka sees things better than at another time, it is just a matter of luck when the solution is found exactly.
Regards, Eelco
-
cpuchess
Re: Position Analysis - Same conclusions at different times?
Sounds like you could be right. Thanks for the explanation.
-
ernest
- Posts: 2040
- Joined: Wed Mar 08, 2006 8:30 pm
Re: Position Analysis - Same conclusions at different times?
Try it with 1 thread only (Max CPUs=1)cpuchess wrote:Sounds like you could be right.
You will see that your result is reproducible (provided you clear Hash)
-
M ANSARI
- Posts: 3707
- Joined: Thu Mar 16, 2006 7:10 pm
Re: Position Analysis - Same conclusions at different times?
Yes with MP engines you will find quite a bit of difference in how fast they reach a certain move. MP engines are non determenistic and a lot of it has to do with how each core is assigned which moves to investigate first. Sometimes one core gets lucky and get a good "hit" and thus finds the solution quickly ... other times it just takes more time to get a hit since the moves assigned to be checked out are not the best ones. Single processor engines meanwhile will always find the solution at the same time.