Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: BitScan with reset - not so impressive with 3DNow!

Author: Sune Fischer

Date: 07:12:55 12/05/02

Go up one level in this thread


On December 05, 2002 at 09:03:09, Russell Reagan wrote:

>On December 05, 2002 at 04:15:35, Sune Fischer wrote:
>
>>That is not as bad as I thought, but ask yourself how often do you need this
>>information.
>>I think you will be needing it a lot when you begin building a sophisticated
>>eval().
>>I don't believe it is a good idea to do the whole design of the engine around
>>the move generator alone, you should consider what you will be needing in all
>>the other phases. Ie. if move generation is 20% of your time and eval() is 50%,
>>then you really ought to be more worried about how to optimize the evaluation
>>and choose some structures that aren't too information limited/expensive.
>
>I had not considered this. Where do you think I would need a faster
>piece_on_square() type function in the evaluation?

Given it is a chess program, it seems only natural to have a fast way checking
what kind of piece is on some square. You might check where it is used in
Crafty, think its call PcOnSq().

Suppose you generate captures first, except for en passent moves you have no
idea what kind of piece you are capturing, unless you go by the pattern
generation like Steffan suggested.

>>>I'm starting to really like this. Non-rotated bitboards, no need for a
>>>first_one() type function, and virtually no lookup tables.
>>
>>Don't you need to index the zobrist table, for instance?
>
>I didn't think of this either. I'll have to think about this some more. It might
>be possible to compute the new hash key during move generation when I know the
>piece type and how the position is going to change.

Yes it might be possible, but already you could run into problems with
techniques such as ETC where you generate the key before making the move (else I
think it's going to be way too slow).

So okay, you don't have to use ETC, but already doors are closing infront of you
because certain things are are very expensive for you to do.

It may be a matter of flexibility versus speed. It certainly is easier to design
for speed when you know what you need and what you can do without.

-S.

>Russell



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.