Author: Robert Hyatt
Date: 20:03:36 09/21/01
Go up one level in this thread
On September 21, 2001 at 20:42:34, Eugene Nalimov wrote:
>GCC uses CMOVs. MSVC does not. So you can see yourself that CMOVs only hurts :-)
>
>Eugene
:) I assume you mean "hurts portability among processors" and not "hurts
speed?" :)
>
>On September 21, 2001 at 14:58:27, Robert Hyatt wrote:
>
>>On September 21, 2001 at 13:56:45, Eugene Nalimov wrote:
>>
>>>I believe explanation is even simpler. Of course it all depend on the compiler,
>>>but probably for the code
>>> (x == y) & (u == w)
>>>it generated something like
>>> t1 = 1
>>> if (x == y) goto L1
>>> t1 = 0
>>>L1:
>>> t2 = 1
>>> if (u == w) goto L2
>>> t2 = 0
>>>L2:
>>> t3 = t1 & t2
>>> ...
>>>So you have *both* mispredicted branches and memory accesses.
>>>
>>>Eugene
>>>
>>
>>
>>no CMOV's???
>>
>>
>>
>>
>>>
>>>On September 21, 2001 at 09:55:02, Robert Hyatt wrote:
>>>
>>>>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]; }
>>>>>}
>>>>>
>>>>>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.
>>>>
>>>>It depends on the cost of accessing both halves of the &/&& operation. &
>>>>needs both, && might bail out on the first. But then && will have two
>>>>jumps, while & will have one.
>>>>
>>>>In your case, the branch misprediction seems to overwhelm the cost of
>>>>fetching both operands for the "&" operation.
>>>>
>>>>
>>>>>
>>>>>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.