Author: Vincent Diepeveen
Date: 16:17:31 09/08/02
Go up one level in this thread
On September 08, 2002 at 15:02:36, GuyHaworth wrote: > >I don't think Rob Hyatt and I are in disagreement about the parallelisability or >distributability of EGT generation. I can't imagine Bob saying that it's impossible to generate EGTBs at a cluster, so in that case i have to agree with you saying it's possible. Note that at supercomputers i/o speed = RAM speed usually. All you need is bandwidth of course and as we see above that's no real issue here. In case of multiprocessor machines it's even easier as you only have to start a few more threads each pass. Please consider that a pass of KRBP KQR is really slow compared to 5 men. Each pass in itself you can already divide in several threads. The basic thing with 6 men is that they are very impracticle to use in games. Suppose you have a harddisk with 150GB (or 2 terabyte in case of Nalimov's DTMs) of 6 men *all 6 men* with win/draw/loss. That's *right* now, pretty impracticle with regard to the access. I can't afford in my pc a fast SCSI 150GB disk simply. Next year we will see of course what the price is of them by then, but right now it's just too expensive for me to buy it. That's the only reason i never generated them so far. Of course Nalimov by now has a small advantage that he has already all pawnless ones, but i wonder how he's going to store all the ones WITH pawns and what time it takes to generate them for him. I need 4 GB of RAM to generate the 6 men with pawns, so i basically waited for someone to offer a machine with 4 GB ram to start generate them. beutlerhvac did :) >Distributability: an example. There is nothing to stop computer A generating >KQQKQP while computer B generates KQQKRP. All they require is that KQQKQQ/R/B/N >and KQQKRQ/R/B/N have been generated first. > >There is plenty of 'width' available in the lattice of endgames to allow >independent generation of EGTs. > > >Next, one can distinguish phases in the generation of an EGT: > >a) the initialisation of the EGT ... terminal and transition positions > this is a major piece of work and commonly underestimated > >b) [ optional phase but available with twin-sourcing: > confirmation that the initialisation of the EGT-generation is correct ] > >c) retrograde or repeated-sweep generation of the EGT > >d) independent validation of the integrity of the EGT generated > > >Within 'c', a further opportunity for parallelisation exists > >c1) [ notional: divide the range of the EGT-index into N parts ] > >c2) have processor 'k' back-up the frontier positions in part k of the index > >Agreed: you would not start the next retro-phase until all N processors >complete here. Shared memory is needed for this, not to mention multiple >disc-drives. > > >In summary, EGT-generation is as parallelisable as required: >resource-availability is the only limit. > >g
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.