Author: Ross Boyd
Date: 16:47:04 06/20/04
Go up one level in this thread
On June 20, 2004 at 12:25:05, Uri Blass wrote:
>On June 20, 2004 at 12:13:59, Uri Blass wrote:
>
>>On June 20, 2004 at 07:44:25, Ross Boyd wrote:
>>
>>>On June 20, 2004 at 07:20:11, Uri Blass wrote:
>>>
>>>>On June 20, 2004 at 06:00:58, Ross Boyd wrote:
>>>>
>>>>>My engine (coded in C) uses longjmp() to terminate a search.
>>>>>
>>>>>Is there any disadvantage or hidden overhead in this approach?
>>>>>
>>>>>I notice other engines use a flag which is tested at every node of the search.
>>>>>Surely there's an overhead in doing it that way????
>>>>>
>>>>>I suppose the main drawback of longjmp() is portability. Most languages other
>>>>>than C don't support it.
>>>>>
>>>>>Am I missing something?
>>>>>
>>>>>Ross
>>>>
>>>>Tscp also is using longjmp()
>>>>I did not read most of the code of other programs.
>>>
>>>Yes, and that's where TRACE inherited it. :-)
>>>
>>>>
>>>>I do not know if most languages do not support it.
>>>>Basic that was the first language that I wrote small programs with it has the
>>>>goto command that is similiar.
>>>>
>>>>I also do not understand the connection between other languages and portability.
>>>>
>>>>Do you think to translate trace to program that is not written in C?
>>>
>>>Yes, by portability I meant cross-language (not cross platform).
>>>I have no plans to translate TRACE to another language. :-)
>>>
>>>Mainly, I was wondering why most don't use longjmp(). It seems to me longjmp()
>>>has less overhead than testing everywhere whether to return to root. And it
>>>keeps the code simple and efficient.
>>>
>>>Ross
>>
>>I do not understand why it has less overhead.
>>
>>I check every 8192 nodes if to return to the root.
>>I do not see what is the difference if I do it by longjmp() or by another
>>method.
>>
>>You always need to check a flag at every node by something like if
>>((nodes&nodefrequency)==0)
No Uri, I didn't mean that test. I meant the one that appears after every call
to search(). eg. PSEUDOCODE
// MAKEMOVE LOOP
while moves
makemove
value = -search(-beta,-alpha, depth -1)
takeback
// abort_search gets set when time is exceeded or user interrupts search
if (abort_search)
return(0)
endif
... usual beta cutoff stuff goes here
endwhile
>I mean that you always need to do some if in every node.
>I do not see a logical way to avoid it and I guess that the price of additional
>if is less than being 0.1% slower so it is not important but maybe I guess wrong
>because I know that crafty does not check capturing the king in SEE and Bob
>claimed that it means that it is going to be slower if he needs to check if the
>capture piece is the king in order to finish the search.
>
Yes, there must be a little overhead but it is probably not worth worrying
about.
>Note that it is against my intuition because my intuition tells me that checking
>if the king is captured should do the code faster because it means that you save
>time by not calculating more captures after capturing the king
>when crafty calculate more captures after capturing the king in SEE so maybe the
>price of one additional if is more than what I consider.
I have a test in my SEE for capturing the king but its probably a waste of time.
Standard SEE is inaccurate anyway - but its probably better than no SEE at all.
It would be nice to have one that correctly evaluates pins without hurting speed
too much. I think using hashed SEE results may be something to consider.
Ross
>
>Uri
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.