Author: Steven Edwards
Date: 13:33:56 03/17/05
Symbolic: Status report 2005.03.17 Symbolic's ChessLisp interpreter had about 2K lines of code removed as a result of deleting implicit support for position search trees and position search nodes. Formerly, both types were realized with extensive toolkit support to take advantage of pre-existing C++ classes and things worked well for a while. However, with the integration of the new IDB (Instance Data Base) subsystem with an IDB attached to each sufficiently interesting position node, some calculated values were then stored in two places and that's always a bad idea. It was too difficult to handle synchronization issues and there was also the lesser hazard of non-trivial redundant calculation. Furthermore, the earlier representation of trees and nodes as run time created symbols with extensive property lists did not really save that much time even though nearly all the work was done in C++ space; lots of nodes meant lots of unique node symbols meant lots of extra global bindings, and that meant a general interpretation slowdown. (The ChessLisp interpreter spends a plurality of its CPU time performing symbol binding lookups.) Position search trees and nodes are now implemented as association lists. As can be imagined, this change affects a lot of already written Lisp source and I'm still working on propagating the new arrangement. But it's worth the effort as the result will be a clearer and more transparent Lisp program with fewer dependencies on the interpreter. A side benefit is that it now will be much easier to port Symbolic's Lisp source to an independent Lisp interpreter or compiler. I doubt that I'll ever bother to do this, but it's nice to have the option. -------- Some work has been done with the IDB subsystem so that an IDB can remember which production sets have been run. The idea here is to implement a "just in time" feature with the hope that efficiency can be gained by not running a production set unless and until it becomes absolutely necessary to do so. -------- Currently, Symbolic's ChessLisp interpreter (an instance of the C++ class SyEnv) is created fresh at the start of each cognitive search (an instance of the C++ class CTCogSearch) called for each move selection. This interpreter creation is fairly quick; less than 200 msec on a 700 MHz PowerPC. Alas, the first thing the interpreter has to do is load Symbolic's Lisp source files and this takes around 800 msec on the same machine for only about 5K lines of source. The scary part is that the Lisp source will easily grow to tens of thousands of lines as many hundreds of chess knowledge productions are added, and this means a big increase in the per search overhead. My thought here is to move the SyEnv instance out of the CTCogSearch instance and move it into the single CTK (kernel) instance where it only has to be initialized and loaded once per program invocation. In fact, on dual processor machines, it might be worthwhile to have a pair of SyEnv interpreter instances initialized at start time; they could alternate between running a search and terminating/initializing for the timewise adjacent searches.
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.