Computer Chess Club Archives


Search

Terms

Messages

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

Author: Johanes Suhardjo

Date: 12:46:55 04/04/05

Go up one level in this thread


On April 03, 2005 at 01:07:08, Russell Reagan wrote:

>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

How true!  Thanks for sharing your experience!
                                              Johanes



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.