Author: Uri Blass
Date: 09:25:05 06/20/04
Go up one level in this thread
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) > >Uri 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. 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. 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.