Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: To bitboard or not to bitboard?

Author: Johan de Koning

Date: 00:29:44 09/01/03

Go up one level in this thread


On August 31, 2003 at 08:22:10, Tord Romstad wrote:

>On August 31, 2003 at 08:03:48, Uri Blass wrote:
[...]
>>2)Do you consider the time of updating your attack tables as part of the
>>time of your evaluation?
>
>Yes, it is part of my evaluation function.  While I loop through all the
>pieces and the squares they attack, I do various other things simultaneously
>(like checking if a rook is on an open file or supports a passed pawn,
>and assigning bonuses for that), in order to avoid having to loop more than
>necessary.  Therefore I cannot easily move the attack table generation
>out of the evaluation function without slowing things down.

I'm not so sure about your conclusion.
Doing multiple things in one loop puts tremendous pressure on the available
registers. On 386 machines you have only 7 (assuming you don't abuse sp :-).
Once 7 is not enough, speed collapses. Because some locals are in mem, because
you lose another register for temps, because the compiler gets confused and
makes you lose even more registers.

This maybe one reason your program has a low N/s rate on a PIV.
But I'm just guessing here, since I don't know if you're comfortable with
watching assembly listings or with profiling. And I might add that my program
also rarely reaches 200 kN/s on a PIV 2.4. But then again, PIVs are not very
chess friendly.

Anyway, splitting functionality might not be a bad idea since it leads to
simpler, smaller, faster code. And of course, it reduces complexity on the
source level. As an eg, I would certainly move rook support to the rarely
called passer eval. And if you have decent activity, you can lose the concept
of rook-on-open-file altogether. :-)

... Johan



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.