Author: James Swafford
Date: 19:22:21 10/14/02
Go up one level in this thread
On October 14, 2002 at 13:51:25, Robert Hyatt wrote: >On October 14, 2002 at 08:59:37, James Swafford wrote: > >>On October 14, 2002 at 06:34:43, Vincent Diepeveen wrote: >> >>>On October 14, 2002 at 04:29:41, Daniel Clausen wrote: >>> >>>>On October 13, 2002 at 22:48:10, Jeremiah Penery wrote: >>>> >>>>>On October 13, 2002 at 21:40:42, Robert Hyatt wrote: >>>>> >>>>><snip> >>>>> >>>>>>You are _totally_ wasting your breath... >>>>> >>>>>I don't mind too much wasting my breath, as long as some decent discussion comes >>>>>from it. :) >>>> >>>>As if that ever happened on this board when the subject was related to DB. ;) >>>> >>>>Sargon >>> >>>the marketing hype created by IBM is so big that we'll never end >>>talking about it, like they talked for well over 100 years about >>>The Turk automata that won from Napoleon. >>> >>>it's pretty weird to see people argument that the thing searched 18 >>>ply fullwidth based upon some mainlines, despite statements and >>>theoretical impossibilities to do so :) >> >>Please defend that statment. Why is it theoretically impossible >>to search 18 ply full width? Doing some back of the envelope >>calculations, I get >> 4.0^18 = 68.7 B nodes >> 3.9^18 = 43.6 B nodes >> 3.8^18 = 27.3 B nodes. >> >>(27.3 B nodes) / (.126 B/Sec) == 217 seconds < 4 minutes. >> >>What's impossible about a bf of 3.8 and a search of 217 seconds? >>Note Hsu didn't claim 18 ply _every_ search. He said 12 ply >>and up to another 6. >> >>-- >>James > >I have tried that line of reasoning. No results. Even though the log from game >one >showed an EBF of around 4.0, Vincent will _not_ let that keep him from his >appointed >agenda... I have not studied DB logs, and I am not an expert on DB. I'm confused as to why Vincent claims they did no forward pruning and therefore cannot achieve 18 ply (implying somebody falsified statements, everybody is mistaking about Hsu's comment about 12(6), etc.) if the log shows they got a bf of 4.0 for game 1. It is clear to me that if they got a bf of slightly less than 4.0 in _some_ positions, then 18 ply is not out of reach. It's also clear to me that you can't get that kind of bf without hashing and/or some form of pruning. So the argument over what kind of search depth they got can be reduced to what their ebf was, which can be ... answered directly from the logfiles? What's the argument about? Somebody please provide me a URL to the DB logfiles so I can see for myself. -- James > > >> >> >>> >>>Amazingly no one ever talks about shredder here. Shredder always shows >>>longer mainlines. Some years ago i had a selective search in diep which >>>checked the principal variation of diep further. >>> >>>In the end i threw it out. >>> >>>Now suppose you have 480 processors idling, i'm so amazed no one can >>>understand that in order to get more nodes a second, the only >>>important thing, even the chat yesterday Hsu was only talking >>>about nodes a second NOT about search depths, it is important to >>>give them jobs. >>> >>>So splitting a position at the end of the pv 1 deeper is not so stupid >>>here. The rest is from hashtable and extensions. >>> >>>The only interesting question this Jeremiah Penery guy should ask himself >>>is: "WHAT WAS IBM BUSY DOING?" >>> >>>Answer: getting as many nodes a second as possible against kasparov >>> >>>Now how do you get as many as possible CPUs to work in order to >>>get more nodes a second, with just a small search depth? >>> >>>All we know is that even at 11 ply search depths they didn't manage >>>to get the full potential of the cpu's. In fact 126 MLN nodes a second >>>is a lot less than 480 x 2.25 MLN nodes a second = 1.08 BLN >>> >>>126 MLN nodes a second is 11.7% from that. >>> >>>That's basically based upon the last seconds of the 3 minute search. >>> >>>the first few seconds not many processors had a job out of 480. >>> >>>So what i do then is to already let them split mainline second ply >>>after root. I put a bunch of processors there, despite possibly >>>getting a different alfabeta score. >>> >>>For a 2 processor setup that's horrible for the speedup (gives a >>>very bad speedup). For 480 processors it's great, getting them >>>busy is very important! >>> >>>In fact we see from the deepblue paper in 2001 that it was already >>>taking processors from a search job if it took a bit too long to >>>search it! Then it resplitted and added more cpu's. That automatically >>>means that you get a longer PV. >>> >>>Best regards, >>>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.