Author: Robert Hyatt
Date: 13:19:43 12/20/03
Go up one level in this thread
On December 20, 2003 at 10:13:18, Vincent Diepeveen wrote: >On December 20, 2003 at 08:43:37, Thomas Mayer wrote: > >>Hi Vincent, >> >>>I did 2 experiments: >>> >>>experiment A) I ran diep at 460 processors with 115MB hashtable *in total* >>>experiment B) Same diep version at 460 processors with 115GB hashtables. >>> >>>Note hashtable means transpositiontable here. Each processor had local 4.2MB >>>pawnhashtable and each processor had local 32MB evaluation table. >>> >>>MB = 10^6 , GB = 10^9 >>>#probes = 4 >>>entrysize = 16 bytes >>>position = r4rk1/p1q1nppp/b2b4/2nP4/1P3p2/P1N2N2/B1P3PP/R1BQK2R w KQ - >>> >>>What is the expected outcome? >> >>well, there are several unclear facts - e.g. how to usage of 460 processors is >>different to the usage of 1 processor etc. >> >>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 ?! :) >> >>Greets, Thomas > >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". I ran this test a few years ago. The answer for my program was this: Going from a very small (but not impossibly small) hash table to one that is way too big and can store the entire search and then some, made a difference of a factor of 2.0 to 2.5 depending on the middle game position. IE back then I went from something like 48K to some big upper bound, and the raw search time to a specific depth was at best 2-2.5X faster. In the middlegame. Which is maybe a ply. In the endgame it is huge. Of course, I'll save you the trouble, and say that this is with my crappy program, using my crappy hashing algorithm, with my crappy search, with my crappy quiescence search that doesn't hash at all, and with my crappy evaluation. So a less-crappy program might do better. Of course, in your case, it would be _better_ if you tested a program without any _bugs_. Results produced by a program with significant parallel search bugs is not very reliable or interesting.
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.