Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Looking for tips for writing a _fast_ move generator.

Author: Russell Reagan

Date: 22:07:08 04/02/05

Go up one level in this thread


On April 02, 2005 at 06:22:12, Anson T J wrote:

>Rather than claim to know best and get stuck in, I would like to ask people here
>with experience. Which board representations and methods of generating moves
>have proven to be the fastest?
>
>Are there any intuitive methods for generating moves that are also very fast? I
>am hoping to get around 1.5 million moves per second on an AMD XP 2400+
>
>If someone could point me to a nice web page or give any other tips I would
>greatly appreciate it. I am trying to write this generator in Delphi as my
>knowledge of c is rather limited.


I will offer you the best advice you could hope for when it comes to this topic,
based upon my personal experience and years of wasted time.

1. Write simple, clear code in a generic, modifiable way.
2. Do not worry about how fast it runs. If you followed rule 1 you can make it
fast later.

It doesn't matter if your move generator is ten times slower than everyone
else's. Write it in such a way that you can replace it later, and replace it if
you can actually prove that the move generator is a bottleneck in your engine
and needs to be replaced (but I doubt you'll be able to prove it, because it
won't be a bottleneck). Even if it is ten times slower than most move generators
(which I also doubt), your program might run 20% slower overall than if you had
written a "fast" move generator, and there are at least ten thousand better
ideas to try which will help your program play better than making it run 20%
faster (which will result in no more than a single digit ELO improvement). Not
to mention that the fast, clever code will probably contain bugs.

Instead, focus on exponential improvements, like choosing good algorithms, and
discovering good enhancements to those algorithms. Algorithmic improvements can
make your program exponentially faster, instead of some small constant like 20%.
My experience was that attempts to make a "fast" program only made a buggy
program, and I usually ended up throwing the thing away and starting over.

I can confirm that the following statements are true. I thought they were
exaggerations the first time I read them. I learned the hard way that they were
not.

"Debugging is twice as hard as writing the code in the first place. Therefore,
if you write the code as cleverly as possible, you are, by definition, not smart
enough to debug it." -Brian W. Kernighan

"Many jobs worth doing aren't worth doing right; a novelist is foolish to
agonize over each word in a shopping list." -Jon Bentley

"Premature optimization is the root of all evil." -Donald E. Knuth



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.