Author: Vincent Diepeveen
Date: 10:26:54 10/17/02
Go up one level in this thread
On October 17, 2002 at 11:34:35, Uri Blass wrote: >On October 17, 2002 at 10:41:20, Robert Hyatt wrote: > >>On October 17, 2002 at 06:13:26, Johan Melin wrote: >> >>>On October 16, 2002 at 23:35:10, Robert Hyatt wrote: >>> >>>>On October 15, 2002 at 14:01:35, Johan Melin wrote: >>>> >>>>>On October 14, 2002 at 07:34:16, Bas Hamstra wrote: >>>>> >>>>>>Bob, did you read the Hsu transcript posted here? It is pretty clear to me that >>>>>>Hsu himself says 12 ply fullwidth *total*. Case closed. Please read the complete >>>>>>transcript. >>>>>> >>>>>>Best regards, >>>>>>Bas. >>>>> >>>>>I agree. The transcript with Hsu is clear. But it would be out of character for >>>>>CCC if everybody just agreed with each other, there still has to be a fight ... >>>>>;) >>>>> >>>>>/Johan Melin >>>> >>>> >>>>Here is the relevant part of the transcript: >>>> >>> >>>There are other relevant parts? How about: >>> >>>---------------------------------- >>>EeEk(* DM) kibitzes: kib question from ardee: Does "12(6)" mean 12 >>>total ply or 12+6=18 total ply? This has the been source of huge >>>arguments for years! >>>CrazyBird(DM) kibitzes: 12 total in terms of brute force. 6 is just >>>the max partition in hardware. >>>---------------------------------- >>> >>>He sais 12 _total_. He also refers to 6 as "just", implying that it is less >>>important than the 12. >> >> >>No he clearly did _not_ say "12 total". He said "12 plies of brute force". He >>also >>said elsewhere that the _hardware_ does forward pruning. So "12 plies of brute >>force" >>implies that is non-hardware... > >It is not clear from it. > >suppose the hardware never pruned in the first 3 plies in the hardware when the >hardware get depth 6. >Suppose also that the software sent the hardware only lines of at least 9 moves. >You can have 12 plies of brute force when 6 is the maximal depth in the >hardware. going into details how the software and hardware divided itself is not very interesting, because it was so very inefficient. Also the moves it played were horrible. It never doubts also, which amazes me. You concluded it is a preprocessor. If it is, then it is searching dubiously because i conclude clearly that it is not cleaning its hashtables, where i cannot disagree with your preprocessor conclusion. the forward pruning in hardware was of course dubiously done. It is in hardware too difficult to take previous SOFTWARE mainlines into account. Doing the 2 times repetition in hardware is already hard enough. In IEEE99 Hsu describes how many gates some for us trivial things need. For software trivial things, they are very difficult in hardware. Anything done in software is independant from the hardware obviously with exception of the 2 times repetition and the board position you have now and the single bound it has now. Note that a single bound creates a big problem to detect singular extensions in the mainline. It DID do 1 singular extension the first ply in hardware. See the artificial intelligence article (deepblue.pdf). I already concluded years ago that the IBM team had a wrong implementation of singular extensions. Missing loads of singular moves. They had to limit it bigtime, because otherwise you never get to 12.2 ply on average fullwidth. the big bugs in extensions in the hardware and the combination of forward pruning there which didn't take into account anything in software, means in short that it is pretty clever in software when a search of say 5 ply takes too long, to make 1 more move in software and divide all those moves over the different processors. It is not hard for me to realize that when you get 480 processors just 2 weeks before the match starts, that it is impossible to get them efficient parallel to work. It is very happy to see for us that the deep blue machine only searched in reality on average around 250k nodes a second at each hardware cpu. If i give to you a 500 processor machine with 1Ghz McKinleys and such a simplistic program like deep blue (like 40 patterns in eval and very simplistic 'gnuchess' mobility, and not even knowing about doubled pawns like at g2,g3 or g7,g6). Then i am sure you will get more than 126MLN nodes a second easily :) Even in terms of absolute speed, the machine isn't unreachable to todays standards. Of course i don't ask you to search very efficient at those 500 cpu's then, just 12 ply is enough to get similar deep :) Of course you can get more nodes a second easily by removing nullmove and you can forward prune a bit last few plies to not suffer too much from extensions. And you can even try more conditions there than you can do in hardware. Your proposals to at least search 12 ply is interesting, but of course not practical to put in hardware, because the decision takes 1 extra cpu clock then. What i am lately wondering about is that when the machine searched 300-400MLN nodes a second in far endgame, how little nodes a second must it have searched in openings phase to get to 126MLN a second? Best regards, Vincent >> >> >> >>> >>>If somebody tells you that "the storage capacity of this harddrive is 20 GB, 5 >>>GB is just the linux partition", then what is the storage capacity? 25 GB? >> >>No. But nobody has said that. they have said "20 gigabytes of space". >>The hardware has 5 gigabytes of buffer." Does the thing have 20 gigs or >>25 gigs _now_??? From a speed perspective, it matters how that is done. >> >> >>> >>>---------------------------------- >>>EeEk(* DM) kibitzes: question from parabola444: You mentioned Deep >>>Blue searched about 12 plies brute force + extensions, which is >>>similar to what pc programs these days get on a fast pc - since Deep >>>Blue hardware was much faster, how come it didn't search significantly >>>deeper ? >>>CrazyBird(DM) kibitzes: to all the book readers, if you do like the >>>book, please tell your friends would might be interested. thanks. >>>CrazyBird(DM) kibitzes: replace would with who:). >>>CrazyBird(DM) kibitzes: we were using fairly extensive search >>>extensions, and the decision not to use null move pruning was an >>>deliberate one. >>>---------------------------------- >>> >>>The interesting part here is not just what he says, but what he doesn't say. If >>>they search 18 plies nominal, he would have said so. Why would he hold back such >>>a statement? He indirectly agrees to searching only 12 plies. >> >>Again, Hsu tries to answer what he is asked, as briefly as possible. The >>hardware does >>forward pruning. They have _always_ given the "software depth" when they >>discuss >>this kind of number. Whether he still is is up for debate, but I doubt he would >>suddenly >>change his terminology after using it for 15 years... >> >> >> >> >>> >>> >>>>----------------------------------------------------------------------------------------------------------------------- >>>>CrazyBird(DM) kibitzes: 12(6) means 12 plies of brute force (not >>>>counting the search extensions & quiescence). >>>>CrazyBird(DM) kibitzes: 6 means the maximum hardware search depth >>>>allowed. >>>>CrazyBird(DM) kibitzes: this means that the PV could be up to 6 plies >>>>deeper before quiescence. >>>>----------------------------------------------------------------------------------------------------------------------- >>> >>>Note that in the first line he states "not counting ..." but does not mention >>>any extra plies from hardware. Wouldn't 6 plies be more significant than >>>quiescence? So why doesn't he mention that it isn't included in the 12 plies? >>> >> >>What about the last sentence. It seems to say exactly what you say is missing. >> >>"up to 6 plies deeper". > >up to 6 plies deeper relative to the logfile. >I do not know if they did extensions in the hardware but even if I assume that >they did ply can include also extensions. > >When people says that the program search 6 plies it includes extensions so it is >possible that when 6 plies are missing it includes extensions. > > >> >> >> >> >>>> >>>>OK, some questions: >>>> >>>>1. If 12(6) means 12 plies total, with 6 done in hardware, how do you reconcile >>>>that >>>>_last_ sentence above (the PV could be up to 6 plies _deeper_ before >>>>quiescence). >>>>Deeper than what? Only possible answer is deeper than 12 plies. >>> >>>He is talking about the PV. Their hardware return a score, but no PV. So >>>sometimes they didn't get a complete PV, and say "the pv COULD BE UP TO ...". >> >> >> >>That makes no sense. They don't limit the 12 ply search to 6 plies of >>extensions >>total. So he is not talking about search extensions. Saying "the PV could >>be up >>to 6 plies deeper" is _obviously_ not a reference to the missing pv from the >>hardware >>for many reasons. First, if the hardware is searching 6 plies, the PV would not >>be >>"up to 6 plies more" it would be "at _least_ 6 plies more because of the >>hardware search >>extensions + qsearch". > > >> >> >>> >>>> >>>>2. If 12(6) means 12 plies total, with 6 in hardware, what does 4(5) mean? 4 >>>>plies total >>> >>>Uri Blass suggests aggresive extensions that increase the remaining depth. >> >>Again, that makes no sense in this context. It would _instantly_ have to resort >>to a >>hardware-chip only search if the above means 4 plies brute force, 5 plies of >>that done >>by hardware. > >I do not see the problem. > >It is possible that deeper blue extended 4 plies for the first 3 plies so the >first 3 plies were done in the software and the last 5 plies were done in the >hardware. > >plies is used in a different meaning here but the meaning is clear. >last 5 plies means depth 5 for the hardware and first 3 plies means first 3 >moves. > >Uri
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.