2

I'm very curious to know which one is run fastest in the CPU among i++, i+=1 and i=i+1 and how can I measure their execution time?

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
user3928757
  • 256
  • 2
  • 5

3 Answers3

4

Well, at first the mankind invented the following record.

i = i+1;

then along with achievments in hardware the mainkind invented the following record

i += 1;

and at last due to the progress in the computer sciences the mankind invented the following records

++i;

and 

i++;

All these three forms of records are expressions of the same set of machine instructions.(with a minor exception for ++i and i++ when they are parts of some more complex expression):) And this set of machine instructions does not depend even on the level of the compiler optimization.:)

P.S. Of course we are discussing these operators for fundamentals types. There is no any sense to discuss these operators for user-defined types because they can be overloaded in various ways.

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
  • 1
    actually depends on level of compiler optimization – Iłya Bursov Mar 21 '15 at 05:41
  • @Lashane I am sure that you are wrong. Maybe for some compiler it depends on level of optimization but for good compilers it does not depend. They are simply formal records of the same mchine instructions. – Vlad from Moscow Mar 21 '15 at 05:44
  • @Lashane: The important part is that it *has no reason* to depend on the compiler optimization. – AnT stands with Russia Mar 21 '15 at 05:44
  • it has reason: depending on optimization level, code around will be different, different registers, cache state, etc. As naive example - without optimization compiler will generate add/inc instructions, with optimization - it could remove these operations at all and calculate value at compile time – Iłya Bursov Mar 21 '15 at 05:47
  • @Lashane What you just have written entirely unrelated to the forms of records. – Vlad from Moscow Mar 21 '15 at 05:50
  • 1
    @VladfromMoscow related, with optimization turned off some compilers (even "good" ones) will not attempt to analyze expression at all, just perform straight conversion, thus, depending on target processor and optimization level `i++` and `i=i+1` will produce different results, in x86 terms `inc`/`add` for =P6 (just because add is faster, not because compiler determined expressions equality), you can experiment with MS one (especially old one - not sure if it is "good" or not) – Iłya Bursov Mar 21 '15 at 06:56
1

Take a time stamp, and execute one of them in a loop and a timestamp when you exit the loop. Loop 1 million times, and compare the results for each loop (e.g. one timed loop for each different type). If you're on an embedded system or something that's really slow, reduce the number of iterations. You just need enough loops to achieve a noticeable difference.

Compilers are different, and they optimize. A good compiler probably generates the same code for each, so you might not see any difference.

Use the highest resolution time stamp generating function your OS provides (like microseconds or nanoseconds). If you can't get a high enough resolution timestamp function increase the number of times you iterate so you can make a meaningful comparison.

Also turn optimization off and see if times generated are different. See if you can get the compiler to show you the machine language equivalent to get even more understanding.

clearlight
  • 12,255
  • 11
  • 57
  • 75
  • I don't think this is reliable because the OS may interrupt the loop when handling interrups and other tasks and might even give a time slice to another process.. – Paul Ogilvie Mar 21 '15 at 09:49
  • Good point. You could negative nice it to raise its priority or even bump it into a realtime scheduling class, depending on the *NIX like OS. You could also run the program many times and take an average. But if you loop for a significant number of times then the averages should be close enough because the OS would have no tendency to interrupt one loop more than another. But it does mean that nanosecond resolution would not yield additional precision. – clearlight Mar 21 '15 at 14:15
1

Unless you have a severely damaged compiler, these will all generate the exact same code. Try it and look at the output of each.

Jonathon Reinhart
  • 132,704
  • 33
  • 254
  • 328
  • I'd add note that depending on optimization level code could be different, also code around this instruction will affect (because of cache, hyperthreading, etc) generated code too – Iłya Bursov Mar 21 '15 at 05:29