Author: Eugene Nalimov
Date: 10:25:15 03/22/99
Go up one level in this thread
On March 22, 1999 at 08:14:06, Robert Hyatt wrote:
>On March 21, 1999 at 15:38:29, Mark Young wrote:
>
>>On March 21, 1999 at 15:15:34, Paulo Soares wrote:
>>
>>>On March 21, 1999 at 14:03:18, Robert Hyatt wrote:
>>>
>>>>On March 21, 1999 at 13:15:23, Paulo Soares wrote:
>>>>
>>>>> In 1989 the HD approximately had a capacity of storage of 30 Mb.
>>>>>Today they have approximately 8Gyb, or either, approximately 250x more
>>>>>capacity of storage of data. In year 2010:
>>>>> 8*250=2Terabytes
>>>>>This not influence in Ed' tournamant(computerxcomputer) but
>>>>>what the influence in computer x humans games in the openings,
>>>>>endgames(tablebases) and midlegames?
>>>>>
>>>>>Best regards,
>>>>>Paulo Soares,from Brazil.
>>>>
>>>>
>>>>things haven't improved _that_ much. In 1985 we bought a machine with a
>>>>couple of 1 gig disks. On the PC platform (IDE) I bought a Toshiba Notebook
>>>>in 1986 with a 40 mb disk, and had SCSI been available back then (on a PC)
>>>>they could have had 1 gig disks...
>>>>
>>>>Today's disks are at 50 gigs max. with 20-30 gigs being pretty common (I just
>>>>bought a 17 gig disk for 300 bucks at Comp USA (IDE)). So in 10 years we have
>>>>increased by maybe a factor of 50, which is more realistic...
>>>
>>>
>>>Robert,
>>> Then we will have HDs with approach capacity
>>>of 50x20=1Terabyte. You know much about the endgames
>>>tablebases, what you find that would happen? 7 pieces,
>>>9 pieces, in the endgames tablebases?
>>>
>>>Best regards,
>>>Paulo Soares
>>
>>I'm not an EGTB expert, but I see how much space it takes jumping from just 4 to
>>5 pieces tables. That make me think even with a Terabyte drive, 7 and for sure 9
>>pieces tables will still be out of reach. Bob, with todays fastest super
>>computer. How long would to take to make a 9 pieces EGTB? Any Idea.
>
>
>yes, and I don't want to think about it. :)
>
>IE figure a week to do krpkr + promotions. the 6 piece files are 64 times
>bigger, but _far_ bigger in terms of time, because we have to iterate for
>each mate-in-N. And no one knows what kind of mate-in-N thing we might see
>with 6 or 7 piece files. On a good supercomputer, Lewis Stiller did a few
>6 piece endings, but they were pawnless I think, which reduces the mate-in-N
>distance to something close to manageable. But a real 6 piece file with one
>(or more) pawns might take a year at present, and need a _huge_ amount of real
>memory to prevent that from paging into 10 years.
>
>We're a ways away...
Stiller in his dissertation gives DTC (not DTM - they will be larger)
for some classes of 6-man endings:
KRNKNN 243
KRBKNN 223
KRNKBN 190
KQNKRR 153
KRNKBB 140
KRRNKQ 101
etc.
Please note that all those endings are pawnless, so, according to the
rules, actual DTC cannot be more than 50. But for endings with pawns
it still can be 200. Or even 500.
I thought about generating 6-man endings. I even found some multi-CPU
Xeons (with 4Gb of RAM and 100Gb of disk storage) in our labs that
I can use during nights and weekends. There are still many problems:
1. Major modifications of generator are necessary:
(a) It must use disk-based instead of RAM-based algorithm,
(b) It must use 16-bit counters during the generation (resulting
table can be coded using minimal bits encoding, or be
compressed using technique similar to current compression
schema),
(c) It must use 8-bit counter for "50 moves rule" (it's possible to
pack both (b) and (c) in 18-20 bits instead of 24, but saving
is not worth extra complexity). Several 5-man endings must be
re-generated as well. It looks that those counters must be
present in final TB, too.
(d) It must use 64-bit arithmetic for index calculations.
(e) It must handle files that are larger than 2Gb. It's necessary
either to split those files into smaller chunks, or write
non-portable code.
(f) It's necessary to write SMP part. Task by itself is easy -
problem can be parallelized (or how to say it in English) very
well, but it still shall be done.
(g) Generator must save intermediate results after each iteration
(or possible after half of the iteration) to disk, and be able
to restart after interruption.
2. Average pawnless ending will contain ~2.5x10**10 positions. After
compression that still be ~5-10Gb. Ending with pawns will be
~3 times larger. I have no means to transfer that amount if
information to users (Bob). Maybe DVD?
3. It looks that we can use smaller Win/Draw/Loss TBs in the search,
and probe full TBs only at the root. WDL TBs are approx. 5 times
smaller than the full ones, and potentially can be compressed
better. A lot of research is necessary.
Main problem is lack of my time. I'm very busy right now, more than
I was several months ago.
Eugene
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.