Author: Miguel A. Ballicora
Date: 21:22:58 09/20/01
Go up one level in this thread
On September 21, 2001 at 00:01:42, Antonio Dieguez wrote:
>
>hi Dann
>
>if (turno==0)
>{
> if (eval0id1[indice]==p->idHashseg && eval0id2[indice]==p->idHashseg2)
> { return cualeval0[indice]; }
>}
>else
>{
> if (eval1id1[indice]==p->idHashseg && eval1id2[indice]==p->idHashseg2)
> { return cualeval1[indice]; }
>}
>
This might not be the answer to your question but it could be useful:
sometimes, if you are willing to sacrifice readibility and speed is critical
you can replace
if (a==b && c==d) {
do_something();
}
by
if (0 == ((a-b) | (c-d))) { /* avoids mispredictions caused by && */
do_something();
}
it could be faster in some cases. Of course, is prone to bugs if you use
it everywhere.
Regards,
Miguel
>you said to me the other day that putting &s there was faster in the profiling
>you did.
>That operations seemed expensive, I supose because are big arrays. And usually
>if one is false(wich I guess happen at least 80% of the time) then both are
>false. So I was puzzled why the & is faster there.
>
>be well.
>
>
>>>can you tell me?
>>
>>Depends on a zillion things. Sometimes, you cannot make that translation.
>>
>>For instance, if you want to substitute & for &&, then you must have both
>>operands be boolean (IOW: _ONLY_ take on the values 0 and/or 1).
>>
>>This is not a valid translation:
>>int a = 1;
>>int b = 2;
>>
>>if ((a && b) == (a & b) puts("My compiler is broken);
>>
>>
>>If the cost of evaluating the operands is very high, then it may be better to
>>use &&.
>>
>>Example:
>>
>>if (foo() && bar()) then foobar();
>>
>>Suppose that foo() is fast, and bar() is really slow. Further, foo() is 0 most
>>of the time. Then you would rather have the short circuit evaluation and
>>branch.
>>
>>Missed branch predictions are expensive on newer chips, but it is not always an
>>easy thing to see when one method is faster than the other.
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.