Author: Vincent Diepeveen
Date: 15:47:08 09/09/02
Go up one level in this thread
On September 09, 2002 at 16:41:20, GuyHaworth wrote: >V > >I will not attempt to compare parallelisability of EGT-generation on (a) SMP and >(b) NUMA machines. > >Getting an EGT-generation code that: > >a) transparently exploits available SMP parallelism >b) can be used by a distributed community of volunteers >c) has the community's work controlled by software at 'EGT central' > >would be a big step forward. > > >We agree that inverse-index functions can be 'difficult' and surprisingly slow. > > >We agree that EGT-initialisation is complex. Independent verification of the >EGT is also slow, especially if the successors of a position are not all >clustered closely in the same partition of the EGT (as now). >Eugene has been able to duck these last two issues. He generates mates in 1, 2, >3 ... in turn (all DTM algorithms are constrained to do that) but he does so by >repeated 'linear sweeps' of the whole EGT-in-build. >A 'Ken Thompson' retro-algorithm works backwards from the 'frontier' of >last-identified wins ... and does not look at all the positions in the EGT. With all respect of course Ken Thompson was a pioneer who's work will never be forgotten and always appreciated, but you can't compare Ken Thompsons worldwar I aircraft with the subsonic jumbojet from Eugene. Working backwards is not needed of course. Only a non-chessplayer would invent something like that... > >Note that the Wu/Beal DTC/DTM algorithm (ICGA_J and IS_J) needs only 1-bit per >position in RAM (+ some buffering memory) and serialises all passes of the EGT >during build. Obviously i'm using that Thompson idea too. How else can you generate at a PC all 6 men in RAM? All i need is 4 gigs of RAM to generate all EGTBs in ram. Parallellizing it when being in ram is trivial, but only needed when the processor is the slowest obstacle. When using inverse functions obviously the processor is. >If discs and disc_I/O_channels are used intelligently, parallel action can be >instigated here. I suspect that the bit- and byte-vectors used by Wu/Beal can >be compressed/decompressed to advantage to/from disc ... but no-one afaik has >tried this yet. >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.