Author: GuyHaworth
Date: 13:41:20 09/09/02
Go up one level in this thread
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. 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. 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.