Author: Robert Hyatt
Date: 20:46:22 12/21/03
Go up one level in this thread
On December 21, 2003 at 09:19:16, Vincent Diepeveen wrote: >On December 20, 2003 at 16:19:43, Robert Hyatt wrote: > >>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: > >test ran for 10 hours. So it searches like half a trillion nodes which all get >stored to hashtables. > >So any hashtable size is going to be very small compared to that... ...also >115GB RAM usage. Can we stay on the same page for a short time? When I ran the test, I started with a hash table so small that it was almost non-existent. I then doubled it over and over until the search time stopped decreasing. It would not matter whether I ran on a 386/16 and started at 3kb, or a 2.0ghz opteron and started at 3mb. That's not the issue. What you asked and what I answered was "how much speedup?" I said 2.0 to 2.5 was what I found using Crafty and varying the hash size from something way too small, and continually making it bigger until things stopped speeding up. > >At supercomputer i store the qsearch in the own hashtable of each cpu, so that >is the global hashtable but only local used. Each processor allocates > >115G / 460 = 250MB hashtable local or so for each cpu. > >Then the same thing for 115M / 460. > >So in both cases loading factor is *real* big. What does that have to do with your question? Make the cpu 100X faster, make the hash 100X bigger, nothing has changed... > >>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.