hello,

my friend tell me :

unsigned int v, mask
.../..
if(v & mask)

is really incredeable faster  on core2 than

unsigned long long v, mask
..../..
if(v & mask)

because it exist micro-instruction and 
with "immediate 32" but not with "immediate 64"

he have right?

thx. 

Bruno Causse wrote:
> hello,
> 
> my friend tell me :
> 
> unsigned int v, mask
> ../..
> if(v & mask)
> 
> is really incredeable faster  on core2 than
> 
> unsigned long long v, mask
> .../..
> if(v & mask)
> 
> because it exist micro-instruction and 
> with "immediate 32" but not with "immediate 64"
> 
> he have right?

Depends on the mask. There is no 64-bit immediate, but you can do a 
64-bit 'and' with a sign-extended 32-bit immediate mask.

On x64, you have enough registers, so sacrificing a register for a mask 
is much less of an issue than on IA-32.

"Bruno Causse" <pasdespam@MUNGED.microcosmotalk.com> wrote in message
news:4a69c0dc$0$5650$9a6e19ea@unlimited.newshosting.com...
>
> my friend tell me :
>
> unsigned int v, mask
> ../..
> if(v & mask)
>
> is really incredeable faster  on core2 than
>
> unsigned long long v, mask
> .../..
> if(v & mask)
>

Is the mask a variable - as you posted - or is it a constant?  Masks in C
are usually constants.  It makes a difference as to what instructions are
likely to be generated.  If the mask is a variable as you posted, it's
likely that the binary-and instruction will be between registers or memory
and register.  In which case, there is no code with an immediate.  I.e.,
your question (below) about immediates doesn't make sense.  If the mask was
supposed to be a constant, then you'll likely end up with instructions using
immediates.  I.e., your question makes sense, but your examples aren't
correct C.

A 64-bit compiler's sizeof(long long) is commonly 8 (64-bits).  But, the
sizeof(int) varies.  Is your compiler's sizeof(int) equal to 4 (32-bits) or
8 (64-bits)?  It's likely 4.  Most 64-bit C compilers use 32-bit int's and
64-bit pointers and long long's.  It's called an LLP64 or LP64 data model.
But, others use 64-bit for all three.  Those are called ILP64 or SILP64 data
model.

So, depending on your compiler's data model, compiler's emitted code, and
your code, you could have a many different possible combinations for the two
examples...  Many things are possible.  It's possible the compiler is
generating an 32-bit immediate form for both - which would mean something
else is going on.  It's possible the compiler is generating register-memory
instructions for the "unsigned long long" case which are slower than
immediates.  This might be accessing non-local or uncached memory slowing
everything down if the cpu's cache is very fast compared to main memory.
It's also possible the compiler is generating multiple instructions for the
"unsigned long long" case to generate an _unsigned_ 64-bit binary-and.
Whereas, a binary-and with a _signed_ "long long" might be using a single
instruction.

One thing to check is that a 64-bit constant isn't within the range of a
64-bit value created by sign-extending a 32-bit value.  I.e., in hex you
want to make sure the upper eight half of the 64-bit constant isn't 0's or
F's.  The compiler could truncate it to 32-bits as an optimization.

> because it exist micro-instruction and
> with "immediate 32" but not with "immediate 64"
>
> he have right?

That's one possible explanation.  But, as I see it, there could be a quite a
few others...


Rod Pemberton

Rod Pemberton <do_not_have@nohavenot.cmm> wrote:

> Is the mask a variable - as you posted - or is it a constant?  Masks in C
> are usually constants.  It makes a difference as to what instructions are
> likely to be generated.  If the mask is a variable as you posted, it's
> likely that the binary-and instruction will be between registers or memory
> and register.  In which case, there is no code with an immediate.  I.e.,
> your question (below) about immediates doesn't make sense.  If the mask was
> supposed to be a constant, then you'll likely end up with instructions using
> immediates.  I.e., your question makes sense, but your examples aren't
> correct C.
> 

yes, constant, sorry,


> A 64-bit compiler's sizeof(long long) is commonly 8 (64-bits).  But, the
> sizeof(int) varies.  Is your compiler's sizeof(int) equal to 4 (32-bits) or
> 8 (64-bits)?  It's likely 4.  Most 64-bit C compilers use 32-bit int's and
> 64-bit pointers and long long's.  It's called an LLP64 or LP64 data model.
> But, others use 64-bit for all three.  Those are called ILP64 or SILP64 data
> model.
> 
> So, depending on your compiler's data model, compiler's emitted code, and
> your code, you could have a many different possible combinations for the two
> examples...  Many things are possible.  It's possible the compiler is
> generating an 32-bit immediate form for both - which would mean something
> else is going on.  It's possible the compiler is generating register-memory
> instructions for the "unsigned long long" case which are slower than
> immediates.  This might be accessing non-local or uncached memory slowing
> everything down if the cpu's cache is very fast compared to main memory.
> It's also possible the compiler is generating multiple instructions for the
> "unsigned long long" case to generate an _unsigned_ 64-bit binary-and.
> Whereas, a binary-and with a _signed_ "long long" might be using a single
> instruction.
> 
> One thing to check is that a 64-bit constant isn't within the range of a
> 64-bit value created by sign-extending a 32-bit value.  I.e., in hex you
> want to make sure the upper eight half of the 64-bit constant isn't 0's or
> F's.  The compiler could truncate it to 32-bits as an optimization.