Author: Robert Hyatt
Date: 10:29:26 01/17/00
Go up one level in this thread
On January 17, 2000 at 11:13:44, Vincent Diepeveen wrote: > >It's impossible to get fullwidth without hashtables at chessprocessors, >with the way parallellism was set up, >and without the chessprocessors communicating hash etcetera with each >other to get 15 ply fullwidth, WITH a load of extensions. > >Note tha No it isn't. I did the math for you already. Crafty would likely do about 19 plies on that hardware. Take away 2 for null move R-2, so I would probably see 17 without null move. If I did the full SE implementation as done in DB, Hitech and Cray Blitz, I would lose another 1-2 plies. So make that 15. If I did some of the other extensions we did in Cray Blitz, plus the newer idea Hsu mentioned about extending when there are two "almost-singular" moves, 14 makes a lot of sense, math-wise. And not counting the hardware processors was pretty common for them with chiptest. You can pretty well confirm this easily. Look at their logs, and find a position where things are _very_ quiet. Look at the depth (say 6 plies), and at the PV which will also have exactly 6 moves in it. Why is that interesting? Easy: The chess hardware does _not_ pass a "path" back to the SP. The chess processors return (a) a best move and (b) the score. No other information at all about the PV it searched is provided. This seems to say that whey they say "10 plies" that they mean "10 plies on the SP hardware, + 4 plies in the chess hardware". I don't see any other way to interpret their output, although I could easily be mistaken. So their "11 plies" is 11 plies in software + the chess processor search of another 4 plies (and remember the hardware didn't do SE and the like.) t Hsu describes that a typical 12 ply search was first 4 ply >at processor 1, then 4 ply at 30 different processors, then 4 ply in hardware. > That was an example. Read his dissertation. Because they _obviously_ search 4, 5, 6, 7, 8, 9 etc as well. The algorithm must be adaptive, except that the chess processors do 4 plies period. >>anywhere, so it isn't easy to decide. For me, 1M nodes per second gives a >>depth of 13-14 in the middlegame. Going 200M should drive that to roughly >>log3(200) which is about 5 plies deeper. So call that 18-19 plies. Removing >>null-move would subtract 2, so 16-17 plies. Singular extensions 1-2 more plies, >>so that would be (14-15) to (15-16) plies. >>Somewhere on their web site they mentioned 14 plies as "normal". So their >>iteration number might be slightly different from "ours". IE when I search >>until depth is reduced to zero, I go to the quiescence search. They might >>go to their hardware, which is not exactly a "quiescence search" since it looks >>at all moves for 4 plies, but doesn't do any of the singular stuff and so forth. >>I'll try to ask next time I hear something from Hsu. > >He implicitly answerred that in april this year, apart from that it's >fullwidth not possible given the way it was implemented with all the >conditions and extensions. > I didn't see anything that addresses this from Hsu. It is certainly possible because I could do it with my current program, given hardware about 200X faster than my quad xeon. Without any trouble at all... >Deep thoughtII searched many tens of millions nodes a second and got 10 ply. >deep blue was more NPS optimized, and got just a ply or at most 2 ply >deeper. very logical. > Deep thought II _never_ searched "many tens of millions of nodes per second". Hsu reported several times that they hit about 2 Million. Which, if you remember the formal name, he called it "deep thought .02, because he thought it was only a 'fraction' of what the real "deep thought" would do one day (this before going to IBM and renaming it to Deep Blue of course.) >Vincent
This page took 0 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.