Author: Russell Reagan
Date: 01:15:46 06/09/02
Go up one level in this thread
On June 08, 2002 at 20:55:17, Jon Dart wrote: >My experience is different. I started out with something close to the "classes >for everything" approach, but found that for smaller objects, packing their >contents into into 32- or 64-bit ints was significantly faster. You can use >macros or inline functions to pack and unpack. I actually use the "packing" method within my class. It's implementation is hidden from the class interface, but internally it does the exact same thing you describe. >Inlining is generally a hint, not a command, to the compiler, so you may find >that things you think should be inlined are not, or at least are not always. MSVC++ supports the __forceinline prefix which (as the name implies) forces the function to be inline. >There are other costs. For example, when initializing an array of objects, many >compilers will sit in a loop calling the constructors for each object. If you >know, for example, that the initial class data consists of 0 bytes, you could do >this with "memset" instead - it will be way faster. I agree that there you have to be very careful about things like this. I need to make sure that my data is initialized at startup before any "thinking" begins so that I don't encounter the problem you describe. >There are other reasons why objects can be slower, but these are some of them. I agree that you have to be careful with your objects just as you would when coding in C or any other language. My position is that I have embarked on writing a chess program countless times, and I inevitably reach a point where I wish I could change how a data structure was represented, which would have meant having to rewrite pretty much everything, so I would start over with the current object oriented approach, and after a while I would think "this is overkill" and go back to doing things in C, and the cycle continued. I finally have decided to bite the bullet and spend a good amount of time creating solid objects. My hope is that later on I am going to avoid a ton of bugs and have the freedom to change from 0x88 to bitboard, or whatever change I would like to make. If the price of this freedom and stability is a little speed, that's fine with me, because I probably wasn't going to write a blazingly fast C program anyway. I do not particularly find micro-optimization enjoyable, and there are plenty of other programmers out there who can do it far better than I, so I figure that I will make my program run efficiently and make use of better knowledge. That's my main motivation in this anyway. I have TONS of evaluation function ideas that I have been writing down in my notebook for years. The only problem is that I have had no chess engine to test them with. I have countless ideas about how to solve a lot of problems that currently exist in computer chess, such as the "never" concept where a computer simply doesn't know that something in the game can "never" happen. I think it will take me the rest of my life to test all of these ideas, and even though most of them will probably not work, it should be interesting :) Russell
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.