Is the a value I can set a double to that I can test efficiently i.e. not usual double comaprison? double x= INIT_VALUE; while (huge loop) { if (testifINIT_VALUE(x)) Do this; else Do that; } For example, perhaps INIT_VALUE could be a negative number - then maybe there is way to detemine whether x is negative by looking at a single byte somewhere?
A double is only four bytes and your CPU should be able to access the whole thing in a single go; single byte access is likely to be slower than accessing the whole lot. Have you run some profiling and really found this to be the bottleneck, or are you just assuming (probably wrongly) that it will be? Why exactly do you think a double comparison will be slow? One way you could solve it, although it won't increase performance, is to use a structure containing a char (i.e. single byte) flag and the double. Use the char as an indicator variable that determines whether the double has been initialised or not, then it's only a single byte comparison.
Thank you for your reply - I can see that you understand my problem exactly. I have always been told that a double comparison would be more expensive than an int or a boolean. BUT I just tried a test and found that there was NO DIFFERNCE at all between boolean or double comparison - see code below. My view that when you check a boolean you are looking at maybe one byte, but considerably more for double. How can processor achieve this in the same time? Code: 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) //MAKE CHANGES 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;
Depends on a few of things: the size of the variables and your CPU architecture. What does sizeof(double) return on your system? What is your system? Most likely if you're using a fairly modern 32-bit PC, all the above code will be small enough to fit in cached memory, maybe even the L1 cache, so it'll just be doing a simple register compare which it can do in a single instruction, just as it would for int, bool etc. Probably those who told you double would be more expensive were brought up on ZX81's and forgot things have progressed a bit since then. The key really is to run a test and see what performs quickly and what doesn't within a relevant scenario. In general yes a double comparison could be slower than other comparisons and double arithmetic could be slower than other types, but the main thing is to profile the code and see where the real slowdowns are.