Author: GuyHaworth
Date: 11:26:34 04/09/04
Go up one level in this thread
There are a number of factors involved here, at least:
a) number of 'unbroken' endgame positions indexed for wtm and btm
b) number of 'moves' or 'unmoves' involved for wt(un)m and bt(un)m
c) program speed, governed by:
- algorithm choice, 'fully retro' as per KT/CW/WuBeal, not as per Nalimov
- programming objective, a combo of speed, maintainability, elegance
- coding quality, esp. re interference between 'separate threads'
- compiler optimisation
- CPUs (speed and number), RAM I/O and caches, disc drive I/O and number
d) metric used:
- DTM requires maxDTM + 1 cycles: 'bitmap efficiency'
- DTC requires maxDTC + 1 cycles: 'bitmap efficiency'
- DTZ requires somewhat more than DTC+1 cycles, not a lot more
currently does not get 'bitmap efficiency' but could, see below
- DTR/DTZr: cannot get 'bitmap efficiency'
will remain about as hard to do as DTZ EGTs are now
JdK's FEG is undoubtedly fast (and 'fully retro' (?) in the above sense) but
unfortunately produces EGTs that cannot easily be verified, and therefore have
not been.
Eugene's EGT format is 'established' but not necessarily fully optimal. There
is an argument for partitioning P-endgame EGTs by fixed-P-formation so that such
EGTs can be generated one 'P-slice' at a time with considerable gain in
efficiency.
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.