Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: kogge-stone, rotated bitboards, "raytracing" - on 32 or 64-bit platf

Author: Robert Hyatt

Date: 08:13:55 09/29/04

Go up one level in this thread


On September 29, 2004 at 05:44:29, Russell Reagan wrote:

>On September 28, 2004 at 17:49:21, martin fierz wrote:
>
>>the main question for me is whether i should bother to rewrite my engine to
>>rotated BB, or to leave it as it is, or to switch to kogge-stone or dumbfill of
>>yours (thanks for sharing!), with the 64-bit future in mind. i'm afraid i still
>>don't know what to do :-)
>
>
>The reason you don't know which data structures are the most efficient is
>because you aren't asking the right question, and even if you did ask the right
>question, you probably don't know the answer ;) If you can tell me *exactly*
>what you *want* to do, then figuring out highly efficient data structures will
>not be difficult at all.

One other point.  64 bits on 32 bit processors is _not_ bad.  Super-scalar
architectures are hard to keep busy (both pipes).  The pairs of 32 bit
operations are therefore generally no more expensive than if there was a single
64 bit instruction, because the pair runs down two independent pipes in the CPU
in parallel with very little additional cost...


>
>My guess is that you, just like the rest of us, don't know *exactly* what you
>want to do. You want to experiment, and what you want to do will change over
>time. It's difficult to optimize a program that is likely to change.
>
>Until you have a fairly stable picture of what you want to do, the best thing
>you can do is write flexible, abstract, modifiable code. You can always optimize
>that kind of code.
>
>I've thought about which board representations are the best since I began chess
>programming about four or five years ago. Here's what I've learned.
>
>When I first started writing chess programs, my entire goal was to make the
>program go as fast as possible. Today, I'd rather have an unoptimized, easily
>modifiable Shredder clone that runs at 1000 nodes per second than a dumb bean
>counter program that gets one billion nodes per second. It is much easier to
>optimize a modifiable, unoptimized program than to implement world class
>evaluation and search enhancements in a fast program.
>
>If you try to write a program that is the fastest at everything, it won't be the
>fastest at anything. You have to choose which things you are fast at.
>
>Basically what I've learned is that board representation doesn't matter if you
>write high quality code. High quality code is easy to modify, and modifiable
>code is easy to optimize.
>
>
>>BTW, i also looked at a version of my raytracer which calls those small
>>diag-attack() and straight-attack() functions, it was significantly slower than
>>the version which writes out everything inline. i had my compiler set to "inline
>>functions: any suitable", but it wasn't inlining these small functions, another
>>surprise! after __forceinline, it got clearly faster but still slower then the
>>written-out version.
>
>
>What compiler?



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.