Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: To bitboard or not to bitboard?

Author: Tord Romstad

Date: 06:23:05 09/01/03

Go up one level in this thread


On September 01, 2003 at 03:29:44, Johan de Koning wrote:

>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.

Thanks for the advice.  I thought "ray tracing" was so expensive that it
was wise not to do it more often than strictly necessary.  I will
experiment with different ways of doing this and see if I can manage to
make it faster.

>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.

Not very.  I can do it, but I hate it.  And on the Macintosh PowerBook
where I do most of my development, it is even more difficult, as I am
almost completely illiterate regarding PowerPC assembly language.

>And I might add that my program also rarely reaches 200 kN/s on a PIV 2.4.

That's interesting and surprising to me -- I thought The King was much
faster.  Unfortunately I haven't tried your program for many years.  The
first chess software I owned was a ChessMachine 16 MHz card with an old
Rebel version and The King 2.0.  I loved both programs, and even today
(perhaps partly for nostalgic reasons) I have more fond memories about
them than of almost all later and stronger programs.

>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. :-)

You are probably right.  Initially I had a bug, and assigned a small bonus
for placing the rook on _closed_ files rather than open files.  Despite
this, my program usually placed rooks on open files, and it took a long
time before I noticed the bug.  Fixing it had no noticable effect on
playing strength.

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.