M ANSARI wrote:
Yeah great performance by DS. I was wondering if this was the cluster version and thus maybe some bugs can creep in.
No, this was an 8 core box.
I didn't want to use the cluster version because I couldn't attend during the tournament. If it had crashed and burned in a game we would have lost all following ones because there would have been no-one to restart it. Not a risk I'm willing to take at the current state of things.
Otherwise what a fantastic performance by DS and look forward for the new version. Will there be a cluster version in DS? When do you expect the latest release to come out?
The plan is to release the cluster version publicly but I have no idea when there will be a next release.
I realy do wish you a good luck in developing Deep Sjeng GCP
I think that your program is one of the strongest candidates to reach Rybka's level and even surpass it....
Dr.D
_No one can hit as hard as life.But it ain’t about how hard you can hit.It’s about how hard you can get hit and keep moving forward.How much you can take and keep moving forward….
Daniel Shawul wrote:I saw it live and I was sure sjeng blundered with a delicate positon where king safety dominates. Well if it is not reproducible then it could be one of those case where HT and mulit processor search produce unreproducible moves..
After Nxe5 it only takes 4 ply to see that f4 wins a pawn (Nd3 Nxd3 exd3 Qxd3). It has nothing to do with kingsafety, it's a simple pawn fork.
It's something I would have expected a 19 ply search to see. It played Nxe5 with a +0.4 score (at 19 ply). After f4 the score dropped almost 2 pawns to -1.4 at ply 3.
I can't actually imagine how this can have happened.
I can imagine it quite easily. In 1984, around Labor Day, we entered a brand new version of Cray Blitz based on what was, at the time, called "Principle Variation Search" which was really just a highly-restricted version of YBW. We were running on 4 cpus for the first time on the Cray XMP, and were playing soon-to-be-GM Stuart Rachaels. We had a winning position and out of the blue played "Bxc6#" and thought we had won. Our opponent promply played bxc6 and "escaped mate". What had happened was that we split at that node with four processors. There were three legal moves. I had apparently incorrectly thought that if a processor had no moves to search, it would finish before any processors that did have a move to search, and so let it back up a score to the previous ply. Problem was, the other three processors finished before the one with no moves to search, probably due to an interrupt or system daemon using that CPU, and after they finished and backed up real (non-mate) scores, #4 dropped in the "I am mated" and that made Bxc6+ become the best move since it appeared to be Bxc6#". I found it and fixed it that night. But it is easy to imagine such race conditions in programs that are either parallel, distributed, or both. It is easier to imagine they do have such races rather than to believe they do not, since the programs are quite complicated.
Actually the bug didn't have anything to do with SMP. I've had very few problems with the SMP support since Deep Sjeng 3.0, mostly because I rewrote it based on what I had learned in Deep Sjeng 1.x/2.x.
Clustering is another matter but as I said this was just the SMP version.
