Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Length of time for Move_Gen()?

Author: Sune Fischer

Date: 02:57:02 02/16/04

Go up one level in this thread


On February 16, 2004 at 05:19:43, Tord Romstad wrote:

>On February 15, 2004 at 17:52:37, Sune Fischer wrote:
>
>>Even more importantly Crafty is, to some degree, generating the movelist
>>pre-sorted.
>>
>>Sorting the moves is one of the really expensive jobs, an optimization here is
>>worth 10 times that of a movelist optimization.
>
>Huh?
>
>I don't do any pre-sorting at all, but sorting the moves is most definitely
>not an expensive job in my engine.  I just had a look at my latest profiler
>output, and move sorting takes 1.44% of the processor time.  When combined,
>the various move generation routines take 4.38% of the time.

I don't believe you can sort the moves in 1.44% of the time, your engine is not
_that_ slow :)

Sometimes a lot of it is left out because it gets inlined, remember to disable
inlining when you profile. If you do part of the sorting inside nextmove() or
search() then it's not so easy to guestimate their overhead.

Anyway, sorting the moves is generally a much tougher task, it's about 5 times
more time consuming than generating the moves, in my engine.

On a few percent of the nodes you might get lucky and get a hash hit and be done
there.
If not you have generate the moves, find scores for all of them (either SEE,
history lookups or whatever), compare them all to figure which one should go
first, make sure the selected move hasn't been tried as a hash or killer
already...

When you add all of that up it takes much more time than generating the list.

The advantage of bitboards in this context is that it's easy to generate a
partial list (captures) and run though this list first.
Since a partial list is smaller is also much faster when you need to extract the
best move (finding the best move of 6 is ~5 times faster than finding the best
of 35).

>Of course, this is yet another proof that it is pointless to optimize
>anything before you have a working program.  It is simply impossible to
>guess where the bottlenecks are before that.

I think the biggest danger of early optimizations is that one might decide later
on a complete rewrite. So my advice would be to not optimize until one is
certain the code will remain in the engine forever.

In other words, don't bother too much with micro optimizations :)

-S.
>Tord



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.