Author: Walter Faxon
Date: 06:42:07 03/28/03
Go up one level in this thread
On March 26, 2003 at 13:42:49, Robert Hyatt wrote: >On March 26, 2003 at 11:13:41, Patrick Götz wrote: > >>On March 26, 2003 at 10:55:19, Robert Hyatt wrote: >> >>>On March 26, 2003 at 08:20:04, Patrick Götz wrote: >>> >>>>Hello >>>> >>>>is there any way to help Eugene Nalimov with my AMD XP 2000+ 1 GB RAM ? >>>>Perhaps we can see the 6 man TBs with additional Computerpower a little bit >>>>sooner . >>>> >>>>regards >>>>Patrick >>> >>> >>>You don't have enough compute power, enough main memory, and almost certainly >>>not >>>enough disk space either. :) >> >>How much i need ? >>I can still buy more RAM and the compute power should be enough to take a little >>task. >> >>regards >>Patrick > > >You need enough disk space to hold all the 5 piece and 6 piece endgame tables, >uncompressed. >I'd suspect a couple of terabytes. > >You need to be able to address files > 2.0 gigabytes. > >You need a _horse_ of a CPU, preferably 64 bits. ---------- I believe that this is incorrect, so I am probably confused... Why do you need to hold the entire tablebase being constructed in physical memory? Why not break up the tablebase into pages, and only back up win/loss depth values between the limited number of live pages you can hold at once? This would require many more "unmove" generation cycles (some function of the number of pages squared, times the maximum win depth), but at least memory locality could be guaranteed, and the work could be split up among multiple machines. The same goes for files. Only the live pages need be uncompressed or even on-line. Files physically larger than 2GB can certainly be split into smaller files, with index translation being done automatically. I could go into more detail, but this seems the obvious way to construct very large tablebases. I thought it was being done this way already. -- Walter
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.