2

Does anyone know why the same piece of code, executed twice, seems to be executed faster the first time than the second time?

I tried the code bellow about 20 times, every time the first execution was faster than the second one.

#include <iostream>
#include <time.h>

void add(int* var) {(*var)++;}

int main()
{
    int var = 0;
    clock_t tStart;

    tStart = clock();
    for(int i=450000000;i--;) {add(&var);}
    printf("%.2fs\n", (double)(clock() - tStart)/CLOCKS_PER_SEC);

    tStart = clock();
    for(int i=450000000;i--;) {add(&var);}
    printf("%.2fs\n", (double)(clock() - tStart)/CLOCKS_PER_SEC);

    return 0;
}

It is really tiny, but still why is there a difference?

1.28s
1.36s
Program ended with exit code: 0

Would I have done something wrong? Maybe has it something to do with how I am timing the thing rather than with the speed of execution?

Thanks

  • OS is throttling your program? – john Feb 27 '18 at 15:08
  • 2
    Did you compile with optimizations turned on? – NathanOliver Feb 27 '18 at 15:09
  • 1
    Is this repeatable? On my system over a large number of runs the times are equal (1.05 sec +/- 0.03 sec or so), with gcc 5.4.1 on Linux/x64 with `-O3`. Due to process scheduling and system load there will always be some random variation. – TypeIA Feb 27 '18 at 15:09
  • Premature optimization is the root of a lot of evil. Is there a particular performance issue you are encountering in regards to doing 450000000 printf ? – Max Feb 27 '18 at 15:29

3 Answers3

1

There could be a million reasons why the speed of the execution was slightly different. It could have ran at the same time the system was doing some maintenance, the system could have outsourced the same thread to other processes, etc.

Also, using clock() to measure for performance is not accurate, as it does not really measure time, but rather CPU cycles. I would recommend using std::chrono::high_resolution_clock. An example of usage can be found here.

Michael Smith
  • 1,271
  • 1
  • 8
  • 31
  • If I'm measuring performance, I'm usually more interested in CPU cycles than wall time, so your second paragraph doesn't make much sense to me. – TypeIA Feb 27 '18 at 15:26
  • @TypeIA It depends what kind of profiling you are doing, I just assumed Baristophon was interested in the execution time based off his question. – Michael Smith Feb 27 '18 at 15:29
0

You don't know what services are running each second by your CPU or what threads are being processed on each run of your code .. think of it as stateless environment variables on each run .

Mohammad
  • 739
  • 7
  • 22
0

As suggested int the comments bellow the question, turning the optimization off solved the problem.

Thanks for your help!