Author: Mathieu Pagé
Date: 06:31:35 08/29/03
>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. Hi, tanks for your help. It's fine to see that i'm not the only programmer thinking that OO code can be as fast as non-OO code. I'll try to re-design my code to get it fully OO. of course, I will try to avoid using base class with virtual functions. I was tinking of using those class: CBoard - State of the game, here will be the bitboards CGame - keep the history of the game, it will have a CBoard as the current state of the game. The treefold and 50 moves rules will probably be handled here (or maybe in CBoard) CMove - Keep some information on a move (from, to, type, pieces, piece_taken) CEvaluator - this class represent an evaluator that will evaluate the game and can have some parameters sets to modify is comportment. CSearcher - Handle most of the search algorithm (dont know if it will be easy to get in a class) CTimeHandler - A class that will handle the clock (decide when it is time to move) Then i will have lots of other class like: CMoveList, CHashTable, CPawnHashTable, CTreeFoldHashTable, COpeningBook (a wrapper), CEgtb, CPngGame (A single game), CPgnFile (group of games), and lots of other things. I'll try (dont know if I'll success) to design this as reusable components. I'd like to have your opinion on my project. Is it possible, is there some more class i should have, what are your experience with OOProgramming while working on a chess engine ? I'd also like to find some documentation on the subject, so ... thanks for your help. Mathieu Pagé pagemathieu at hotmail dot com
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.