Author: Vincent Diepeveen
Date: 06:34:44 12/21/03
Go up one level in this thread
On December 20, 2003 at 11:05:50, Thomas Mayer wrote: >Hi Vincent, > >>> Anyway, let's try a guess and take the idea of Christoph Theron that >>> hashtable doubling is about 7 Elo... We have 10 doublings, so 70 Elos >>> expected... Doubling in speed is expected with around 60 Elos... So I >>> expect a speedup of about 120-150%... How far am I away ?! :) > >> i don't want any elo answer, that's bullshit of course. Above 12 ply (without >> forward pruning and with some extensions and checks in qsearch) another ply >> matters shit. The question asked here is: "what does it matter for search >> depth". > >? Maybe you should reread my statement... Using the Théron rule of doubling hash >size I expect a speedup of 120%-150% in time to depth... Shall I give you a Now it is a factor 1000 bigger to be precise and loading factor is real big when seeing half a trillion nodes which all get stored to hashtable. Even though qsearch will be only stored local at this processor. So there is a bit more than 1/460 chance that it will end up showing in the mainline, knowing that this qsearch pos is part of the PV ;) >number ? That means when in a certain position it takes with lower hash 600 >seconds to a specific depth I expect that it would take only 240 seconds with >the higher amount of hashtables... test i ran both times an hour or 10. This at around 6.x million nps (the first diep version that i compiled for supercomputer during the tournament this experiment was done with. Later versions would get hands down 9.x mln nps there). >The last part of your statement is beyond my understanding - you say that >another ply matters shit and on the other hand you want to know "what does it >matter for search depth"... to me depth and ply has some relation, right ? Can the extra 'elo' a ply gives is not relevant in this discussion. I want to focus upon what search depth extra it gives. >you explain me now what you want ? (Besides, I fully disagree that above 12 ply >another ply matters shit... at least not in my experience with my own program... The games diep lost last 4 tournaments were, not counting a single book error here and there, all based upon bugs in evaluation. So getting another few ply extra would usually not change the move to an other move. On the other hand a small bugfix in evaluation would change the move at blitz levels already or for sure at tournament level. 12-14 ply really is sufficient for now. that diep doesn't get this depth yet is irrelevant for the observation. In fact at depth 10 with a shitload of extensions i see for diep that just evaluation matters. >when you say without forward pruning you mean without anything else then >nullmove with R=3, am I right ?) what i mean is that i blitzed with shredder and whatever Stefan says, i'm not impressed by shredders search. It misses a lot. It's the evaluation from shredder that wins the games though. Basically i guess most say that forward pruning works because their search is simply too inefficient when not using it. It's true that programs like crafty and diep have been optimized for years to search deep without forward pruning. So that might matter a lot. However, some simply overrate the extra elo rating forward pruning gives at tournament level. Shredder8 at 13 ply didn't even see that it loses a pawn on g2 by 3 shuffle moves, where the opponent did see it. Shredder then (in an already won position) dropped a full pawn and something in score (still won the game). The same trick i bet for a search without forward pruning and some extensions is like 8 plies. So for shredder8 if one argues one needs 20 plies i am not going to disagree there as i do not know how shallow it is. For diep trivially all mistakes made in games are just bugs in evaluation, though it's questionable whether you can fix strategic knowledge anyway. >Greets, Thomas 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.