# Why the same program runs faster on an older computer?

I have the same single thread problem, which is something like a simple

#include<stdlib.h>
#include<iostream>
#include<stdio.h>
#include<time.h>
//#include<ctime.h>

int main(){

clock_t start=clock();
for (int i=0;i<100 000 000; i++){
//do something here
}

double duration = (clock()-start)/(double)CLOCKS_PER_SEC;
cout<<endl<<"Total consumption time is : "<<duration<<"seconds "<<endl;
// or use
// printf("\n Total consumption time is : %lf seconds",duration);
system("pause");

return 0;
}


Occasionally when I was running them on different computer: older one with XP OS and Pentium V CPU, newer one with Win7 OS x86 and i7 CPU.

It is very strange that I found the older computer runs the same program significantly faster. Then I found it is general for other similar programs.

Why I got such result? Is it because XP OS is faster than Win7?

• I wonder if it's how you're calculating duration. Maybe this is related?: CLOCKS_PER_SEC not actually clocks per sec – horchler Dec 5 '13 at 16:05
• Try to get rid of most things that will call operating system functions, and stick to strictly numerical code (I assume that's what your program does). In particular, remove all I/O functions (printf, cout, etc.) This should minimize the dependence on your OS version and truly compare the CPUs. (Though the truth is that there are some surprising things that depend on system functions...---I had a similar problem where the same, seemingly purely numerical code ran much faster on Linux than Win) – Szabolcs Dec 5 '13 at 17:56
• Also, try to use timethis instead and make sure your code runs for at least several seconds, otherwise the benchmark may be inaccurate!! – Szabolcs Dec 5 '13 at 17:59

There are so many variables that play into the speed with which a program runs that it is impossible to tell from just your description. For example:

• Did other programs run at the same time?
• What is the clock speed of your processor?
• How was the program compiled and which processor was it optimized for?
• How long does the program run to begin with -- for example, is it within the accuracy of the timer?
• Is the loop simple enough for the compiler to optimize it away?
• Are you timing the entire program execution including loading it, or only the actual run time of the loop?
• If you time the entire program execution including loading, how does the set of shared libraries that the program links to differ?

There are many other questions that make it impossible to answer your question in this generality.

• So virus should also be potential reasons? How can I identify the root causes? – LCFactorization Dec 4 '13 at 15:13
• Sure, maybe a virus too. As for how to find the cause -- go down the list above and see how your systems differ. – Wolfgang Bangerth Dec 4 '13 at 15:44
• Is it possible to compare the CPU clock of different computers? Do you have any idea how to implement it via C++? – LCFactorization Dec 5 '13 at 12:19
• I'm not sure what you mean by compare the "CPU clock". I assume you mean "clock frequency", not "clock time". In that case, you can go to the Windows System Information and see what the CPUs name, generation number, clock frequency, etc is. I'm sure there is a way to query the current frequency from the power management system, but I don't know how to do that on Windows. – Wolfgang Bangerth Dec 5 '13 at 12:36
• actually, the cpu clock frequency may be higher on the older processor – Andre Holzner Dec 5 '13 at 16:54

The faster CPU may be more than made up for by the heavier operating system. If you wanted a true comparison, you'd run the test with the same operating system on both computers.

Moreover, depending on what you're actually doing inside that loop, the program may spend more time on memory reads/writes than floating point operations, in which case the performance is more dependent on the cache than the processor clock speed.

• thank you; is there any way to compare the CPU clock immediately? – LCFactorization Dec 4 '13 at 4:26
• The cpu clock isn't necessarily the controlling factor. See my answer to another question here to see a list. There is a lot that goes into performance. – Godric Seer Dec 5 '13 at 18:49
• Right, it's not just one factor. – Wolfgang Bangerth Dec 6 '13 at 3:27