Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Improvements in BF makes my MoveGen suck =(

Author: Uri Blass

Date: 03:48:25 06/28/03

Go up one level in this thread


On June 28, 2003 at 03:49:57, Albert Bertilsson wrote:

>On June 27, 2003 at 20:04:29, Uri Blass wrote:
>
>>On June 27, 2003 at 19:48:44, Sune Fischer wrote:
>>
>>>On June 27, 2003 at 19:04:04, Steve Maughan wrote:
>>>
>>>>Sune,
>>>>
>>>>>Perft is no good speed indicator anyway, not even for a move gen.
>>>>>The perft tree is so different from the chess tree.
>>>>>
>>>>>Optimizing for perft is basicly like building a formula 1 car to use for
>>>>>off-road rally.
>>>>
>>>>I don't agree.  Perft is *quite* a good thing to optimize.  There are really
>>>>four fundamental foundations of a good chess program -
>>>>
>>>>1) Evaluation
>>>>2) Move Ordering
>>>>3) Make / Unmake moves
>>>>4) Generate Moves
>>>
>>>This "box" thinking is not optimal I think.
>>>It is better to think like this:
>>>
>>>strength = engine(eval,moveordering,make/unmake,genmoves,...);
>>>
>>>There is no reason why you shouldn't be mixing them, like e.g. in Rebel.
>>>
>>>>There are of course other elements (e.g. extension) but these four elements IMO
>>>>are the key elements.  Perft directly measures the performance of the last two
>>>>elements.  Some would say that the speed of move generation is not that
>>>>important and this is true to a certain extent since time spent in the GenMove
>>>>routine is often less than 10%.  However, if you can generate moves quickly you
>>>>will most likely also be able to generate mobility quickly - an element of the
>>>>evaluation function.  So I would argue that perft goes some way to measuring
>>>>three out of the four factors I've listed.
>>>
>>>I can't think if a simple analogy here, so I will give you a mathematical
>>>example.
>>>
>>>Find the maximum of f(x,y) for x,y in [some interval].
>>>You can think of x as move generator and y as eval.
>>>
>>>If you know that f(x,y)=g(x)+h(y) for some functions g and h, then you can find
>>>max for f by maximixing g and h.
>>>
>>>However you do not know such functions exist, and there is no reason to believe
>>>they would. In my experience hybrid functions tend to be the most powerful
>>>solutions.
>>>
>>>If you are determained to get the fastest possible make move, then that excludes
>>>the use of attack tables, this will come back to haunt you in the search and the
>>>eval.
>>
>>And this is also counter productive for perft because if you have fast
>>make move then you cannot use attack tables for faster move generation.
>>
>>I believe that this is the reason that Movei was faster than Sharp in
>>calculating perft.
>
>I think you're right, there are some places in the movegeneration that I know
>would be done faster if Sharper had attacktables. The main reason that Sharper
>doesn't use attacktables yet is that I:
>1. Don't know how I want the tables to look (what I need to get from them when
>ordering moves etc.
>2. I don't have a good idéa of how to generate them efficiently.
>
>I think the main point about studying perft times is that when isolating the
>problem of how to generate and make moves you question what data is needed and
>how to represent it. Good board representation should make fast move generation
>easy!
>
>Also it's really good to have perft to compare with, Sharper still lags behind
>Movei, and that tells me I have missed some clever things in the board
>representation.

I believe that I also missed some clever things.

It is possible that 0x88 may be better but I prefer to try to improve perft by
adding more information and not by changing the data structure that means
changing all the program.

Uri



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.