Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: Parallel algorithms in chess programming

Author: Vincent Diepeveen

Date: 15:51:46 04/18/01

Go up one level in this thread


On April 18, 2001 at 09:04:42, Josť Carlos wrote:

>On April 18, 2001 at 05:25:52, Vincent Diepeveen wrote:
>
>>On April 17, 2001 at 16:07:35, Josť Carlos wrote:
>>
>>>On April 17, 2001 at 14:51:45, Gian-Carlo Pascutto wrote:
>>>
>>>>On April 17, 2001 at 13:30:22, Vincent Diepeveen wrote:
>>>>
>>>>>> Are you sure you spend most of your time in eval? My problem is inCheck()
>>>>>>since ever. That's where my prog spends most of the time.
>>>>>>  The good thing is that, everytime I want to improve the speed of my
>>>>>>program, I know exactly where to focus on :)
>>>>>>  I suggest you to profile your program to know exactly where the time is
>>>>>>spend, although probably you've already done this.
>>>>>>
>>>>>>  Josť C.
>>>>>
>>>>>How can this eat system time anyway?
>>>>
>>>>If you dont have any attack information available incheck can be
>>>>costly. In Sjeng it topped the running profile a long time, though only
>>>>with 15%-20% of the total time or so.
>>>>
>>>>I speeded my incheck/legal_move up greatly by looking at the move last
>>>>played and figuring out if it could possibly have put the king in check.
>>>
>>>  Exactly. That's what I'm doing right now. But actually my makemove() function
>>>is about 5000 lines !!! And I still haven't remove half the inCheck() calls !!
>>>  This is driving me mad, since there're a lot of rare cases that you must take
>>>into account. Really hard, but I hope it's worth the effort.
>>
>>what do you do in makemove?
>>
>>If you do next:
>>
>> if( possiblecheck[piece][fromfield][kingfield]
>>  && scanbetween(piece,fromfield,kingfield) )
>
>  I see. You have all that information stored in a table, so a lookup is enough.
>But anyway, suppose you're already in check. Now you capture a pawn en passant.
>Are you still in check after that?
>  You have to check if the captured pawn was checking your king. Depending on
>whether that's true or false, you much check if both pawns disappearing open a
>line for an enemy sliding piece towards your king. If all of that if false, you
>still need to check if there was another piece cheking your king (it could be a
>double check), etc...
>  I don't see how you know it so easily.

well in diep this problem is of course never happening as i do
attacktables incremental.

if i wouldn't have attacktables incremental and i have a compile flag
to switch'em off, then i simply capture the king from the board and
return mate score if i capture the king.

Just capture the king. Easy.

Why call a function always if the few cases that escape attention hardly
happen?

I don't need to know that i'm in check at all. I just capture the king
if i can get it. It's worth a bit more as capturing a queen of course,
so sorting will quickly pick it out.

You focussed perhaps too much on an exception which rarely happened?


>  Josť C.
>
>>i do not see how figuring out whether such a move is a check can cost
>>more as say 1% system time even in a program getting half a million
>>nodes a second at a PII450.
>>
>>Best regards,
>>Vincent
>>
>>>  Josť C.
>>>
>>>>You can apply a lot of tricks to make this very fast.
>>>>
>>>>Now it is way down on the profile (>3% or so), and my program became about
>>>>6% faster. Now need to find a way to get SEE attack info quicker :)
>>>>
>>>>--
>>>>GCP



This page took 0.05 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.