Author: Robert Hyatt
Date: 12:37:23 10/09/99
Go up one level in this thread
On October 09, 1999 at 13:16:39, James B. Shearer wrote: >On October 08, 1999 at 08:50:37, Robert Hyatt wrote: > >>James... a quick note about your games last night. >> >>I noticed that you played a huge match vs "scrappy" on fics... 70 games >>total. And that out of the 70 games, I found 1 draw and 1 loss. Except >>for the last 3 games, you were playing Crafty as it ran pretty much all >>by itself on the quad pentium pro/200 machine. I have an exam scheduled >>for early next week, and the current programming assignment was due yesterday >>at 5:30pm, so at that time, I 'disallowed' logins on the quad P6 box to >>encourage students to not play around and get ready for the test. > > Actually I had 3 draws (and 1 win) in 73 games. I think this is a bit >below my expectation (of perhaps 4 points). > Drawing 0 increment games against a computer is not so easy. In this >regard it is polite of crafty to offer a draw in KR vrs KR instead of playing on >for 50 moves. It should offer a draw, except in two cases: (1) playing a computer, as the (C) operators are occasionally obnoxious and offer draws when losing. I just have it never accept/offer with (C)s unless I know them personally; (2) if you get below 30 seconds left with no inc (I notice you like 5 0 which is really brave, btw. :) > >>What you saw last night was the 'real' scrappy without any student programs >>running. Scrappy normally runs at "nice 20" so that it doesn't influence any >>student programs that get run, but they definitely kill it when they are >>running. The last 3 games were on a loaded system, if you could tell the >>difference, as the backup process started running in the middle of the night, >>and while it is only one process, it hurts crafty significantly, because I do >>run 4 threads, and 4 threads on 3 cpus (still using nice 20 all the time) is >>(for me) an absolute performance killer, usually being slower than if I used >>only one much slower cpu. > > I probably wasn't at my best for the last few games either. my main problem with scrappy is the nice 20. IE I have 4 threads, running at massively reduced priority. And in the SMP search, it is possible that 3 are spinning waiting on work, while the 4th is waiting on a CPU. a non- dedicated machine _kills_ the overall performance. IE 4 threads on a 2 cpu machine can be _way_ slower than a single cpu machine with 1 thread, the way this code is written. "crafty" on ICC doesn't have this problem as often, as I try to watch when it is playing since the xboard (small version) is visible in the corner of my monitor... but even it suffers when I am doing something serious that consumes cpu time. > >>If you want to play such a match vs crafty, on the quad xeon, that is easy to >>set up and in general, the quad xeon will be 100% dedicated to playing chess >>since it is my machine and I can simply stay off of it during such a match. It >>is about 2x faster (at present, although I am waiting on Intel to ship the 600 >>xeons at the end of October so that I can upgrade the processors to make it >>about 50% faster again). >> >>As I had told you, without students on that box, it is a tough opponent. The >>xeon is tougher and will become tougher still, soon. But it is _very_ difficult >>to draw/win vs even the quad P6 unless you are an IM, when playing at blitz time >>controls. And even then the wins are very few and far between. >> >>If you want to try the xeon, let me know. >> >>BTW the last game (the one you won) was exactly the right kind of strategy for >>a bogged down machine... the ending position was a 'null-move killer' type >>position as it was generally doing 3-4 plies for 90% of that game, where it was >>normally doing 9-12 plies in most of the others... > > The last game was a typical win vrs a computer. The computer already >one pawn up, grabs another on the queenside and gets mated on the kingside. > However I don't understand the 3-4 plies bit. Even if you were slowed >down by a factor of 4 this would be 1-2 plies so you should still have been >getting 7-10. The losing move was 25 Qxb7. Checking with crafty v16.19 Qxb7 is >selected through ply 8, fails low and is eventually rejected in ply 9. for that game, crafty was getting roughly 1% of one cpu. between moves 15 and 40 it was doing almost always 3 plies, with an occasional step up to 4. And on a couple of moves, almost normal depths. Nice 20 (Linux) says give me 5% of one cpu if there is another compute-bound process, and give him 95%. That just crushes the search, and it would probably be worthwhile to turn off threads when it sees this happen. In 5 0 games, on the quad p6, crafty generally does 9-10 plies throughout the game, for reference... >Scrappy's move 27 qc7 was also inferior allowing mate in 5. Again checking with >crafty v16.19, qc7 is first selected in ply 5 then fails low (quickly resolving >to -Mat05) in ply 8 and is eventually rejected. Scrappy apparently saw it was >in trouble as it took 29 seconds on this move (3 times as much as any other) but >was unable to find a better move in time. This is consistent with a depth of >7-10 plies. if 30 seconds isn't consistent on that machine, as it is pretty quick to get thru 8, never taking 5 seconds that I can recall. However, in this position, the current version starts sensing trouble (score drops) and it starts to use more time, which only lets the score drop lower since it is already in trouble. > I think you have an absolute upper bound on search time but in a case >like move 27 where scrappy sees the move it's going to play gets it mated and >still has some time (almost 3 minutes here) it might be better to keep searching >a while. Probably right. the upper bound is 5x the normal target. Which is almost always enough to finish the current ply (where the fail-low has occurred). If it couldn't be 'repaired' another ply isn't going to help, as it still thinks the losing move is best... >In this case scrappy was still dead lost, although it had a couple of >moves which avoided the mate in 5. However that didn't have to be the case, it >could have had a saving move that it didn't find in time. > James B. Shearer
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.