Author: Robert Hyatt
Date: 14:19:30 11/17/98
Go up one level in this thread
On November 17, 1998 at 15:34:15, Eugene Nalimov wrote: >Very rough estimation: > >Pawnless 6-man ending - 10**10 positions. >6-man ending with pawn(s) - 2.5*10**10 positions. > >8 bits per position is not enough, 9-10 bits necessary. >So, pawnless 6-man ending will use 20Gb, ending with pawn(s) >will use 50Gb. > >It's possible to handle huge files at PC using NT (there is >no such restriction on file size as in Linux), but to be >reasonable effective generator must use 1-2Gb of RAM (I'm >speaking not about my generator, but about generator that >is written especially with 6-man tables in mind). Also, you >must have necessary amount of disk space free. how do you address such a big file since (a) the PC has 32 bit words and (b) the ansi standard requires that the data type for fseek() be a "long" and not something obtuse? IE the alpha handles this nicely even under linux... but on a peecee... > >The hardest part will be generation of pawnless endings - >endings with pawns can be partitioned to a lot of subclasses, >depending of the pawns locations. > >Of course you can >(1) Generate on a powerful supercomputer (BTW, task can be > parallelized very well), compress table, transfer compressed > table to PC, and decompress only small chunks when necessary. >(2) Generate not DTC or DTM, but win/draw/loss table - > then you can pack 5 positions per byte. >(3) Generate some subclasses - e.g. with rammed pawns, or > with 2 identical pieces, etc. > >Eugene > >On November 17, 1998 at 13:03:53, Robert Hyatt wrote: > >>On November 17, 1998 at 08:14:45, Mark Young wrote: >> >>>On November 17, 1998 at 08:05:33, Robert Hyatt wrote: >>> >>>>On November 17, 1998 at 06:35:08, Ralph E. Carter wrote: >>>> >>>>>Has anyone projected the size of these? >>>> >>>> >>>>easy to do... for edward's format, use 64* size of previous file. IE for >>>>openings with at least one pawn, two files each with a size of 32 gigabytes. >>>> >>>>Eugene's format is more compact, around 50%. Still *very* *big*... >>> >>>How big a factor increase is adding pawns to the table bases that are 6 ,7 or 8 >>>man. >> >>It really is not a factor. IE if you have a totally pawnless tablebase, then >>a tablebase with a single pawn is bigger, because some of the compression >>tricks can't be used or you will make a pawn move in impossible directions when >>you rotate reflect and mirror the board. But once you have a single pawn on >>the board, every additional piece is roughly 64 time bigger than the last >>one. Eugene actually beats this a bit, so that since some squares are occupied >>(say 5 in a 5 piece ending, going to a 6 piece ending only takes 59* as much >>space (if I calculated that right) and not 64* like the old Edwards indexing >>scheme... >> >>But it really is moot... No PC's allow files that large today, because of the >>32 bit nature of the processor... you can't go beyond 4 gigs on any machine I >>know of until you step up to the alpha/etc 64 bit architectures... Yes it is >>"possible" to go beyond 4 gigs on a PC, but it makes handling the file index >>very messy... and I don't know of a system that does it...
This page took 0.01 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.