C++ double comparison performance

[xmoon2000@gmail]

Hi,

I ran the code beloew but with different version of the "if" statement. Do either boolean, int or double comparisons. Astonishingly, they all give the same order of timings! I would have assumed that boolean would be MUCH fatser than doubles.

Can anyone explain why this is?

Moon





  std::clock_t start;

  std::clock_t end;

  double diff;



  int i;

  int a = 2;

  int b= 3;

  bool ba = true;

  bool bb = false;

  double da = 2.0;

  double db = 3.0;

  double cc;

  string input = "";



  printf("Start\n");

  start = std::clock();

  for (i=0;i<4000000000;i++)

  {

        if (da==db)  //CHANEGS MADE HERE

        {

              cc = 2.0+i;

              da == cc;

        }

        else

        {

              cc = 2.0+i;

              db = cc;

        }

  }



  end = std::clock();



  diff = ( end - start)  / (double) CLOCKS_PER_SEC;

  printf ("Done[%f]: %f\n",cc,diff);

  //getline(cin,input);

  return 0;

[MosaicFuneral]

Immediately read the site rules, particularly on CODE TAGS.

This doesn't prove much....

[Sky Diploma]

std::clock_t start;

std::clock_t end;

double diff;



int i;

int a = 2;

int b= 3;

bool ba = true;

bool bb = false;

double da = 2.0;

double db = 3.0;

double cc;

string input = "";



printf("Start\n");

start = std::clock();

for (i=0;i<4000000000;i++)

{

if (da==db) //CHANEGS MADE HERE

{

cc = 2.0+i;

da == cc;

}

else

{

cc = 2.0+i;

db = cc;

}

}



end = std::clock();



diff = ( end - start) / (double) CLOCKS_PER_SEC;

printf ("Done[%f]: %f\n",cc,diff);

//getline(cin,input);

return 0;

Line 43 doesnt make sense. You seem to be comparing 2 variables not initialising.

[MosaicFuneral]

I should probably tell you that your compiler probably turned this into:

for (i=0;i<4000000000;i++)
    cc = 2.0+i;

or even just did the math before hand(depending on options, and compiler).

It might even turn declare int as a double to compare it, if the int does nothing else.
Depending on the compiler(and options) it's going to use the best instructions for the selected(or default) target architecture, which means the tick deference might not be much.
Or it could do a million things that would effect this poor code.

[StuXYZ]

As MosaicFuneral points out, the compiler can do thousands of things. BUT the best way to find out is to examing the machine code.

Then we learn the following:

The key error in the test code is that you use da/db regardless of the change to the line if (ba==bc) . If you carefully remove that, and stop the strong optimizer settings making cc = 4e7 and skipping the loop. [Well done portland!] then you end up with the the boolean taking slightly shorter than the double on my linux amd 64bit machine under gcc-4.3 and portland. Intel handle integers differently to amd and that is going to change the results as well. Also if you didn't compile your compiler for you exact cpu then you are also going to get rubbish results.

You mileage will differ depending on machine/compiler/OS/Load on the machine. It is normal to do tests a couple of times and THEN do the actual test.

also I dont think you intended to write da == cc in the first if statement (my compiler said statement without effect . It guess you didn't compile with warnings.

The key thing with testing for cpu time, is do it with your real-world problems, then if you make an improvement, you have made a real improvement!