Author: Ricardo Gibert
Date: 13:25:51 10/02/03
Go up one level in this thread
On October 02, 2003 at 11:28:54, Robert Hyatt wrote: >On October 01, 2003 at 20:29:35, Ricardo Gibert wrote: > >>On October 01, 2003 at 13:34:53, Robert Hyatt wrote: >> >>>On October 01, 2003 at 12:07:40, Vincent Diepeveen wrote: >>> >>>>On October 01, 2003 at 11:57:01, Robert Hyatt wrote: >>>> >>>>Remember 1997 when you said it would be impossible to search 17-19 ply >>>>with nullmove, good working hashtable and a few tens of billions of nodes. >>> >>>From the opening position. Yes. Using 1997 hardware... >>> >>> >>>> >>>>Your argumentation back then was that the minimum branching factor was >>>>squareroot of the average number of moves. I have measured that average at 40 >>>>when searching 21 ply from openings position on average. >>>> >>>>So sqrt(40) = 6.32 >>>> >>>>That's what you said back in 1997-1998 in RGCC. >>> >>>Not with null-move I didn't say that. >>> >>>The evidence is too easy to find. It is closer to 3.0.... >>> >>> >>>> >>>>You used 35 btw for the average number of moves, but checks get extended, so >>>>it's in reality 40. >>>> >>>>Now you say 'nonsense' again in 2003 against the statement that >>>>the real problem of a search at a pc where the pc has a loading >>>>factor EXACTLY 500 times bigger, than at a supercomputer, that this >>>>doesn't matter for branching factor at all. >>> >>>What I say is nonsense is your statement that "the deeper I go, the more >>>efficient the parallel search gets." You don't mention any limit to that, >>>which means that efficiency just continues to climb. If so, when you go >>>deep enough you can get there is zero time as efficiency will be infinite. >>> >>> >>>> >>>>I do not know what science you are performing, but it cannot have anything to do >>>>with computerchess and search algorithms. Because you can't even do normal math >>>>there. >>> >>>I think my math holds up. If efficiency continues to climb, it is unbounded. >>>If it is unbounded, then you will reach a point where you search more than >>>N times faster with N processors. That is pure garbage. It always has been. >>>It always will be. >>> >>>All you have to do is stop and think about what you are writing... >> >> >>Here is an example of a formula that always increases as x increases and yet >>remains bounded: y = 1 - 1/(2**x) >> > >That isn't what we are talking about here. That's a function with an >solvable limit. Vincent's already posted his >N speedup stuff for N >processors. If you go beyond N on speedup, I don't see how you are >going to calculate any limit for such a function... > >Simply saying "deeper goes faster" is inaccurate. "deeper goes faster but >the curve is bounded" is much more accurate. Your last statement is inconsistent with your "If efficiency continues to climb, it is unbounded." > > >> >>> >>> >>>> >>>>Vincent >>>> >>>>>On October 01, 2003 at 10:10:26, Vincent Diepeveen wrote: >>>>> >>>>>>On October 01, 2003 at 10:03:26, Vincent Diepeveen wrote: >>>>>> >>>>>>>On October 01, 2003 at 07:45:48, Joachim Rang wrote: >>>>>>> >>>>>>>>On October 01, 2003 at 07:31:53, Vincent Diepeveen wrote: >>>>>>>> >>>>>>>>>On October 01, 2003 at 07:24:24, Joachim Rang wrote: >>>>>>>>> >>>>>>>>>>On September 30, 2003 at 19:33:30, Vincent Diepeveen wrote: >>>>>>>>>> >>>>>>>>>>>On September 30, 2003 at 19:30:30, Dann Corbit wrote: >>>>>>>>>>> >>>>>>>>>>>>On September 30, 2003 at 19:27:38, Peter Collins wrote: >>>>>>>>>>>> >>>>>>>>>>>>>On September 30, 2003 at 19:22:26, Dann Corbit wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>>On September 30, 2003 at 19:14:02, Peter Collins wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>My apologies for the format (from memory) of the position I'd like to analyse, >>>>>>>>>>>>>>>but I am at a terminal outside of where I can access the gamescore: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>Black to make his 29th move: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>3q2k1 >>>>>>>>>>>>>>>5p1p >>>>>>>>>>>>>>>1n2nbpB >>>>>>>>>>>>>>>1P1p4 >>>>>>>>>>>>>>>1Qp3P1 >>>>>>>>>>>>>>>7P >>>>>>>>>>>>>>>1P3PK1 >>>>>>>>>>>>>>>1B2R3 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>Sorry if this is the wrong forum, I'm new here. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>A friend of mine played black against Jeremy Silman..he only looked at about a >>>>>>>>>>>>>>>trillion nodes on slower machines... >>>>>>>>>>>>>> >>>>>>>>>>>>>>[D]3q2k1/5p1p/1n2nbpB/1P1p4/1Qp3P1/7P/1P3PK1/1B2R3 b - - >>>>>>>>>>>>> >>>>>>>>>>>>>Thanks Dan, indeed, this is the correct position. >>>>>>>>>>>>> >>>>>>>>>>>>>I think the one of the best variation so far goes... >>>>>>>>>>>>> >>>>>>>>>>>>>29...d4 30.Be4 d3 31.Qd2 g5 32.h4 gxh4 and from here I am using a 2800Barton, >>>>>>>>>>>>>1.5MB Ram to analyse it. >>>>>>>>>>>> >>>>>>>>>>>>1.5 GB, I suppose. >>>>>>>>>>>> >>>>>>>>>>>>Do you have a preference for what program to analyze with? >>>>>>>>>>>> >>>>>>>>>>>>Many programs will never make it to 24 ply [*] >>>>>>>>>>>> >>>>>>>>>>>>[*] By 'never' I mean that not in several years of continuous time. >>>>>>>>>>> >>>>>>>>>>>at a 486 sure :) >>>>>>>>>>> >>>>>>>>>>>But how about 500 processors? >>>>>>>>>>> >>>>>>>>>>>2 hours or so? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>Diep will never make it to play 24 on your famous 500 CPU-Box. >>>>>>>>>> >>>>>>>>>>regards Joachim >>>>>>>>> >>>>>>>>>junior gets dual 21 ply, shredder searched at a dual P4 in ict3 like 19 in a >>>>>>>>>more complex position than this against diep. >>>>>>>>> >>>>>>>>>i'm not really seeing the problem when i use similar definitions of a ply like >>>>>>>>>them. >>>>>>>>> >>>>>>>>>Best regards, >>>>>>>>>Vincent >>>>>>>> >>>>>>>> >>>>>>>>didn't you wrote that you no longer do stupid pruning? Without extensive pruning >>>>>>>>no program will get 24 plies even at a 500-CPU-Machine. >>>>>>>> >>>>>>>>I don't know your program, but do you actually believe that Diep would reach a >>>>>>>>depth of 24 in two or three hours? >>>>>>>> >>>>>>>>regards Joachim >>>>>>> >>>>>>>i'm using R=3 nullmove. there is no limit on the number of plies you can search >>>>>>>with nullmove. if i limit the extensions, sure 24 ply is not a major problem >>>>>>>when all the search lines end in for example endgame with little possibilities. >>>>>>> >>>>>>>Opening is really the worst case position there. >>>>>>> >>>>>>>a well tuned evaluation function for this position should have no problems >>>>>>>reaching 24 after a couple of hours 500 cpu. >>>>>>> >>>>>>>you have no idea what you're talking about. how many times in your life have you >>>>>>>run with a hashtable of sizes up to 250GB having 512GB ram? >>>>>> >>>>>>compare it with this. how many thousands of years would it take your current pc >>>>>>to generate a 10 TB database? >>>>>> >>>>>>Well at such machines with 512GB ram and the total system having terabytes of >>>>>>striped harddisks i/o and 1 TB bandwidth over the entire machine (0.5 at the 512 >>>>>>processor partition obviously) you talk about other dimensions. >>>>>> >>>>>>Even with a cleaned hashtable after 10 minutes already speedup is 37.3% at 130 >>>>>>cpu's. that gets better and better simply each ply because the BRANCHING FACTOR >>>>>>is better at such machines at big depths. >>>>>> >>>>>>So it is in short exponential better than a PC. >>>>>> >>>>>>If i search 5 ply deeper than normal diep, that in theory would be: >>>>>> >>>>>>3.0^5 = 243 speedup out of 500 processors. >>>>> >>>>>That's nonsense. If that were true, you could eventually search to the >>>>>end of the game in no time. Because the limit of that function is +infinity. >>>>> >>>>>Please do a little math before you post such nonsense... >>>>> >>>>>> >>>>>>Impossible some will say. Well when you give 1 processor 200GB hashtables in >>>>>>total you sure won't find a 243 speedup. >>>>>> >>>>>>However with so many million nodes a second you speak about other dimensions >>>>>>than a PC can handle. >>>>>> >>>>>>I can store *every* node into hashtable. >>>>>> >>>>>>Without that no speedup at all at the machine. But doing that the speedup is >>>>>>magnificent! >>>>>> >>>>>>So the real power shows at long level analysis! >>>>>> >>>>>>Best regards, >>>>>>Vincent
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.