Author: Gerd Isenberg
Date: 02:12:58 11/18/05
Go up one level in this thread
On November 18, 2005 at 03:16:51, Gerd Isenberg wrote:
>On November 17, 2005 at 22:06:49, Dann Corbit wrote:
>
>>On November 17, 2005 at 21:20:01, Daniel Mehrmannn wrote:
>>
>>>On November 17, 2005 at 21:08:06, Dann Corbit wrote:
>>>
>>>>On November 17, 2005 at 18:34:34, Daniel Mehrmannn wrote:
>>>>
>>>>>On November 17, 2005 at 18:13:36, Dann Corbit wrote:
>>>>>
>>>>>>On November 17, 2005 at 17:05:24, Jarkko Pesonen wrote:
>>>>>>
>>>>>>>http://www.uciengines.de/UCI-Engines/TogaII/togaii.html
>>>>>>>
>>>>>>>engine name Toga 1.0MV.6
>>>>>>>
>>>>>>
>>>>>>static int full_search(board_t * board, int alpha, int beta, int depth, int
>>>>>>height, mv_t pv[], int node_type) {
>>>>>>// ...
>>>>>>// I set FutilityMargin in the general case, because some paths
>>>>>>// could leave it uninitialized.
>>>>>> int FutilityMargin = FutilityMargin3;
>>>>>>
>>>>>>Consider the following when depth >= 3:
>>>>>>
>>>>>> if (depth < 2)
>>>>>> FutilityMargin = FutilityMargin1;
>>>>>> else if (depth < 3)
>>>>>> FutilityMargin = FutilityMargin2;
>>>>>> /* else
>>>>>> FutilityMargin = FutilityMargin3; */
>>>>>>
>>>>>>Perhaps futility pruning is never used in such a case, but then if so there is
>>>>>>no harm in setting the value.
>>>>>
>>>>>btw this looks like a very slow coding. It's better to use here switch()/case
>>>>>stuff for an faster code instead the expensive if() stuff.
>>>>
>>>>A switch also branches. The odds of a mispredicted branch are the same.
>>>>
>>>>If a switch were a trillion times faster than an if(), then a change to switch
>>>>in this instance would not speed up Toga by even one tenth of one percent. I am
>>>>absolutely sure of it, without having measured.
>>>
>>>I disagree. Okay, basicly it depends what are you doing and how often it called.
>>>In my experience a switch call is faster than if().
>>
>>In this case, it makes no difference.
>>
>>If you code with switch() because you think it is faster than if() then you are
>>making a terrible mistake[*]. Code with the construct that is the most clear
>>every time.
>>
>>[*] If you have profiled and some patch of code is causing a problem because of
>>slowness and if you see that it is using an if and if it profiles faster with a
>>switch, then change to a switch and explain why you did it in a comment.
>>Else, use if() when it is more natural.
>>
>>P.S.
>>I have profiled chains of if() and switch() statements and arrays of function
>>pointers and many other approaches to conditional changes. Which method is
>>faster will change from compiler to compiler and even from compiler version to
>>compiler version with the same compiler.
>
>Yes - while indirect jump/call was nice until PII (or III), it is worse on
>recent intel and amd cpus - btb does not work here - a branch miss prediction
>occurs, except the code immedialty following the indirect jmp is the right case.
>If else cascades have at least some chanche to become predicted correctly.
>At least a statement like depth < 2 is most often true.
>For G4/G5 it might be that indirect jmp aka switch is faster again.
>Anyway for two, three cases i would prefere if-else-else over switch.
>
>As Joseph already mentioned, to avoid branches here at all - a memory access
>indexed by depth in some way is fine. To avoid even the lookup, some calculation
>by binary "mul" by anding with -1 masks is may already performed.
oups, i mean boolean multiplication...
FM = FM1 + (1 < depth) * (FM2-FM1)
+ (2 < depth) * (FM3-FM2);
... with this Java-compatible standard-pattern to get {-1,0}-masks,
considering 32-bit ints:
FM = FM1 + (((1 - depth) >> 31) & (FM2-FM1))
+ (((2 - depth) >> 31) & (FM3-FM2));
>
>Gerd
>
>>
>>A bit of searching the archives will even show some benchmarks I have provided
>>to this forum in that area [IIRC].
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.