Yeah, yeah, I bet right about now you''re saying "just time the damned thing already!" But I''ll ask anyway

  
if(SomeVar)  //If #1

//compiler generated:  test bl, bl

{
  //do stuff

}

if(SomeVar == true) //If #2

//compiler generated:  cmp bl, 0x01

{
  //Do same stuff

}
  

I ask this because I prefer if #2 for clarity''s sake, but everyone in the past has told me that if #1 is faster. But is there really any difference between a cmp and a test? Thanks Micah.

if (x) is equivalent to if (x != 0). A compiler should generate identical code for both forms.

CMP:
Description


Compares the first source operand with the second source operand and sets the status flags in the EFLAGS register according to the results. The comparison is performed by subtracting the second operand from the first operand and then setting the status flags in the same manner as the SUB instruction. When an immediate value is used as an operand, it is sign-extended to the length of the first operand.


TEST:
Description


Computes the bit-wise logical AND of first operand (source 1 operand) and the second operand (source 2 operand) and sets the SF, ZF, and PF status flags according to the result. The result is then discarded.


Now if I am not mistanking, a SUB command is considerably slower than an AND command.

Regards,
Jumpster

P.S. Source = "IA-32 Intel Architecture Software Developer’s Manual, Volume 2: Instruction Set Reference, with Preliminary Willamette Architecture Information" You can get it at developer.intel.com

'If #1' will be better, because the instruction should take up less memory (2 bytes for #1 versus 3 bytes for #2 [I'm guessing from a little experience - I haven't checked, so please don't flame me if I'm wrong]). Neither is likely to be faster than the other, but as #1 is smaller it will fit into the instruction (L1) cache more easily. This can be an important issue when optimising code, to get as much code to be in the instruction cache as possible, and obviously shorter instructions will help this.

Hope this helps...the smaller instruction will be better

Sorry, I forgot to add - the "cmp register,register" and the "test register,register" instuctions will both execute in one instruction cycle (and can both be paired)

Edited by - NickB on November 29, 2000 2:02:06 PM

NickB:

Your numbers agree with my compiler. (test 2 bytes, cmp 3 bytes)

Ford Prefect:

This is a snippet from a compiled test program. I forgot to show that SomeVar is of type bool (hence the lowercase true). The actual compiler generated code is shown in the comments.

Thanks
Micah

Forget which one is faster. You could run a tight loop doing that compare one million times in a row and you wouldn''t even see 1 millisecond difference. Either way will not affect the speed of your program.

However, I would recommend using the first way. The reason being that false is almost always equal to 0. True is not necessarily always equal to 1. Sometimes true is ANY value other than 0. I''ve run into this a few times programming with MFC where they used 65,535 for TRUE and 0 for false, and it caused a huge bug in my program since I was saying: if (x == TRUE). Since then I always program defensively by saying: if (x).

- Houdini

Houdini,

I''ve ran into that before, but I''m using the C++ bool/true/false not the typedef''d BOOL/TRUE/FALSE. If I''m checking for true/false on any type other than bool (lowercase), then I use explicit checks.

Thanks,
Micah

quote: Original post by MicahJon

Houdini,

I''ve ran into that before, but I''m using the C++ bool/true/false not the typedef''d BOOL/TRUE/FALSE. If I''m checking for true/false on any type other than bool (lowercase), then I use explicit checks.

Thanks,
Micah

Ah, true, true.

Of course, you''ve said that you have ran into that before, either with MFC or another library. The last thing you would want to do is switch coding style between "if (x == true)" and "if (x)" when using different libraries. Since you have ran into the problem before you might as well stick with the safe way of "if (x)".

Not to mention if speed is that important to you, then you prolly should use a BOOL typecasted as an int, because it will be that slight bit faster than c++''s bool (I''m assuming c++''s bool isn''t 4 bytes).

And of course, typing "if (x)" is just plain faster =)

Mind you, none of these reasons are important enough to switch if you are used to a certain style, but if you have no preference and wanted to stick with one...


- Houdini

Houdini,

I had to think which method I use more. After browsing some of my code, I noticed I usually use if(ScreenIsValid) rather than if(ScreenIsValid == true), but I always use if(ScreenIsValid == false) rather than if(!ScreenIsValid). Since I use descriptive variables, the if(x) and if(x == false) read better than their counterparts (and I''m always striving for easy-to-read code).

As for sizeof(bool), Borland uses one byte for bool. I''ve heard many people say "use smaller types for the cache", and others say "use aligned types for access speed". I''ve given up on that, and use whatever makes sense at the time. I figure I can gain more speed with less effort by rewriting slow rountines than I could ever hope to gain by adding (or saving) 3 bytes here and there.

Thanks,
Micah

bool is one byte on MSVC too (i just checked)

...
And for the reasons given above, you''re never ever suppose to do if(x==true), unless you really only care when it''s 1, not when its really true.

Does MSVC have special rules for bool compares? it might... ie it knows to make ==true mean !=false?