Author: Jeremiah Penery
Date: 19:14:19 10/17/02
Go up one level in this thread
On October 17, 2002 at 13:26:54, Vincent Diepeveen wrote: >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. It's also very important to this discussion. >Also the moves it played were horrible. Give me some examples of horrible moves that it played. >It never doubts also, which What do you consider 'never' doubting? Maybe this search: 3(4) 14 T=1 Pe6e5 nf3h4 Bd6b4 4(5) 21 T=1 Pe6e5 nf3h4 Bd6b4 5(5)[e5](21) 21 T=1 Pe6e5 nf3h4 Qd8a5 6(5)[e5](23) 23 T=2 Pe6e5 nf3h4 Qd8a5 7(5) #[e5](-3)###############################[Qa5](1)##[Qb8](13)##[Qe7](19)####[Qb6](20)#[Re8](23) 23 T=9 Rf8e8 pc2c4 Pe6e5 qe1b1 8(6) #[Re8](-1)#[Qb8](4)#################################[Qc7](6) 6 T=30 Qd8c7 pe3e4 Pe6e5 pg3g4 Bh5g6 nf3h4 Bg6h7 9(6) #[Qc7](-1)#[Qb8](1)####################################### 1 T=59 Qd8b8 nf3h4 Pg7g5 nh4f3 Pe6e5 pe3e4 Rf8e8 10(6) #[Qb8](-17)#[Qc7](-7)#[Re8](-6)###[Qa5](-3) -3 T=176 Qd8a5 pa2a3 Rf8e8 nf3h4 Pg7g5 bb2f6N Nd7f6b nd2e4 Qa5d8 ne4d6B Qd8d6n nh4f3 In 7 iterations it only changed its mind 11 times...yes, of course that's 'never doubting'. I can give plenty more examples. I can also give examples of every other program NOT changing its mind during the entire search. It doesn't mean much. But you do know that the better your evaluation, the less you should change your mind, right? >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. What? >the forward pruning in hardware was of course dubiously done. You don't even know what they did, how could you know it's dubious? >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. In the same paper from which you get the number 12.2, they explain how they detect repetition. They don't use mainlines. They keep a count of displaced pieces for the last 32-ply leading up to the current board position being searched. The hardware can recognize a move that leads to a repetition (i.e., a move where there are zero displaced pieces). Of course they have a move stack, but the repetition detector doesn't explicitly need the moves. >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. They only used a single bound in the hardware, not in the software. And they didn't do singular extensions in the hardware anyway, except at the first ply. >It DID do 1 singular extension the first ply in hardware. See the >artificial intelligence article (deepblue.pdf). The software has much more interaction with the first hardware ply than the rest of them, so it's a lot easier to do SE at that ply. >I already concluded years ago that the IBM team had a wrong implementation >of singular extensions. Missing loads of singular moves. Please give examples. >They had to limit it bigtime, because otherwise you never get to 12.2 ply >on average fullwidth. Of course they limit it, but that doesn't mean they 'miss' singular moves. >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). You obviously don't understand their paper if this is what you think. >Then i am sure you will get more than 126MLN nodes a second easily :) What kind of speedup does Zugzwang get using 500+ processors? >Even in terms of absolute speed, the machine isn't unreachable to todays >standards. Nobody's saying it's not. But nobody else has done it either. >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. Removing nullmove does not give more nodes/sec. >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? The maximum sustained speed for one search was 330M, IIRC. If you really want to know the answer, you can do some math and find out how many times they reached a 'far endgame', and estimate the percentage of searches in that phase. Then some simple multiplication can give you a very low estimate for the average speed of the rest of the searches.
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.