Author: Steven Edwards
Date: 01:08:00 08/28/03
Go up one level in this thread
On August 28, 2003 at 02:59:47, Russell Reagan wrote: >On August 27, 2003 at 18:55:03, Mathieu Pagé wrote: >> Is there some documentation about object oriented design of a chess engine ? >One of my many attempts at a chess engine went something like this... > >Color class >Square class >Piece class >Bitboard class >Board class >Move class >Game class >Evaluator class >Search class > >and many other small classes for things like castling rights, en passant square, >and so on. That is all of the main stuff (I think). The CT Toolkit is similar to NextStep / OpenStep / GNUStep / Cocoa in that simple enumerated scalars are represented with enumeration types instead of as classes. >Unfortunately, the classes for small things (Color, Square, Piece, Bitboard, >maybe Move depending upon how you represented it) all slowed things down a >little. I did a little bit of testing, and each class that was just a simple >wrapper for a variable slowed things down. Overall the slowdown was about 40%. The slowdown is dependent on a number of factors. One of them is the use of base classes with member data that increases object size. A big slowdown comes from using class polymorphism as a vtable (or similar) needs to be created (and scanned) for each object of a polymorphic class. My observation is that non polymorphic class objects, particularly those using default constructors and destructors, have no real performance penalty over using C language struct variables. Some compilation options can dramatically decrease run time performance. Support for dynamic type ID can be a killer. Dynamic binding as in Objective C can require a search of a hash table of method names / addresses for each call. Use of the run time exception processing scheme (try / catch / raise) can add a big penalty in some cases. >I think. I've heard people say that you'll get about a 10% slowdown because of >the extra this pointer indirection, and I found this to be true. Of course, when >I have four things that have uneeded pointer indirection, that isn't 10% anymore Don't believe the hearsay. Upon method entry, the this pointer is usually loaded into a particular address register and stays there until method exit. The extra dereference cost is zero when compared to a similar dereference using a stack frame base. Now, it is true that any dereference is slower than a direct access. But the only memory items that can be directly accessed (i.e., no derefencing) are global variables or class static member variables. While the latter is OO, the former certainly is not. Since using a boatload of globals in unacceptable to me, I'm unconcerned about any penalty. Note: using a boatload of class static member variables can be just as bad from a design standpoint as using globals; the use of the word "class" does not magically make a good design out of a poor design. A big savings is gotten by appropriate usage of inline methods that can eliminate nearly all of the method call/return overhead. The CT toolkit has hundreds of these.
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.