Author: Ricardo Gibert
Date: 17:29:35 10/01/03
Go up one level in this thread
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) > > >> >>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.