Author: Aaron Gordon
Date: 00:56:27 11/21/05
Go up one level in this thread
On November 21, 2005 at 03:42:48, A. Steen wrote: >On November 21, 2005 at 03:28:11, Aaron Gordon wrote: > >>On November 21, 2005 at 03:07:08, A. Steen wrote: > >>>Cacheing is thus only a small benefit, as successor EGTBs (sometimes, when >>>post-promotion as opposed to post-capture, about as large) also have to be >>>stored. >> >>That is "caching", by the way. > >Thanks, you lose. Wolf's Law (Typo-Nazi's "first to mention" lemma). > >Your snipping of my refutation of your point tells me all I need to know. > >Your "theory" seems to omit the fact that HDDs are (relative to RAM) absolutely >prehistorically and excruciatingly slow devices, and chess-programming with a-b >hasn't progressed to the stage where you can often usefully proceed with results >pending. > >>>Can I have some? >> >>I think you've had too much already ;) > >No, we were referring to the near-instantaneous HDDs which you seem to >hypothesise about. That is quite interesting, where exactly did you see me post this hypothesis? I'd love to read it. >So, can I have some? > >Best, > >A.S. Considering you don't use a massive chunk of the 3-4-5 EGTB set, setting 256mb EGTB cache works extremely well. The initial load is of little consequence, assuming you're using a fairly modern hard drive. Now, if you were talking about systems from the early 1990's setup with slow hard drives and next to no EGTB cache then I would tend to agree. I have yet to see however in any endgame position at ~3 minutes per move where it has to load more EGTBs than my cache size would allow. If there is such a position, please show me (I am truely interested to see it).
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.