which is faster ?++ or +

[priyanka.js28]

which one of the following will execute faster?
int p=2;
p++; OR p=p+1;OR p+=1;

and y??
is it p++ bcoz it is a single instruction??...nd the rest r multiple...

[Adak]

Depends on how smart the compiler is.

A modern compiler should be able to deduce that the compiled code needed, is the same.

[priyanka.js28]

Depends on how smart the compiler is.

A modern compiler should be able to deduce that the compiled code needed, is the same.

u mean tht the execution tym may varry frm compilr to compilr??

[Adak]

Yes it might - simple lines of code will be evaluated perfectly, by any compiler worth a damn. There will be no differences there.

Better compilers are able to evaluate more complicated lines of code or blocks of code. Their output will be more efficient and thus will run faster, on most or nearly all programs, compared to more primitive compilers.

[Auraomega]

Like Adak said, all the compiler really does is convert your code into assembly (which is basically a set of mnemonics for binary). Any compiler worth its salt will optimise it to be the quickest:

p++;

becomes:

inc eax

Where as:

p += 1;

would become (if the compiler didn't optimise):

add eax, 1

Any compiler, or assembly developer should have enough sense to then change that add into an inc command and take a (I believe) byte less computation and byte less output size.

Overall though with a modern PC you'll never see any difference anyway.

[priyanka.js28]

so can i deduce tht if no optimization takes place, thn p++ executes faster than p+=1?

Like Adak said, all the compiler really does is convert your code into assembly (which is basically a set of mnemonics for binary). Any compiler worth its salt will optimise it to be the quickest:

p++;

becomes:

inc eax

Where as:

p += 1;

would become (if the compiler didn't optimise):

add eax, 1

Any compiler, or assembly developer should have enough sense to then change that add into an inc command and take a (I believe) byte less computation and byte less output size.

Overall though with a modern PC you'll never see any difference anyway.

[Auraomega]

If no optimisation took place, that would be the case, yes.

[Ancient Dragon]

Even without optimization it will be compiler dependent. You can test that out for yourself by having your compiler generate the assembly code and see for yourself what it does with it.

int main()
{
    int x[5] = {1,2,3,4,5};
    int* p = x;
    p++;
    p = p + 1;
    p += 1;
}

With vc++ 2010 express the assembly/machine code generated is below. Notice that all three produce identical code.

; 9    :     int* p = x;

  0004b	8d 45 e4	 lea	 eax, DWORD PTR _x$[ebp]
  0004e	89 45 d8	 mov	 DWORD PTR _p$[ebp], eax

; 10   :     p++;

  00051	8b 45 d8	 mov	 eax, DWORD PTR _p$[ebp]
  00054	83 c0 04	 add	 eax, 4
  00057	89 45 d8	 mov	 DWORD PTR _p$[ebp], eax

; 11   :     p = p + 1;

  0005a	8b 45 d8	 mov	 eax, DWORD PTR _p$[ebp]
  0005d	83 c0 04	 add	 eax, 4
  00060	89 45 d8	 mov	 DWORD PTR _p$[ebp], eax

; 12   :     p += 1;

  00063	8b 45 d8	 mov	 eax, DWORD PTR _p$[ebp]
  00066	83 c0 04	 add	 eax, 4
  00069	89 45 d8	 mov	 DWORD PTR _p$[ebp], eax

; 13   : }

[Adak]

I don't believe you can make any generalizations about compiler efficiency, without testing them, as done by Ancient Dragon, above.

Then you have facts. Without testing, you have hot air, and smoke blowing up your arse. *, and a bunch of unsubstantiated beliefs.

*A reference to the old belief that a person who drowned could be revived by blowing tobacco smoke up their anus.

[Auraomega]

>and smoke blowing up your ****
Sorry, have I done something to offend you as all I seem to get from you is snide and petty comments.

Mingw:

int p = 0;
	
	p++;

becomes:

mov     dword [ebp-4H], 0                       ; 002A _ C7. 45, FC, 00000000
        lea     eax, [ebp-4H]                           ; 0031 _ 8D. 45, FC
        inc     dword [eax]                             ; 0034 _ FF. 00

And:

int p = 0;
	
	p = p + 1;

becomes:

mov     dword [ebp-4H], 0                       ; 002A _ C7. 45, FC, 00000000
        lea     eax, [ebp-4H]                           ; 0031 _ 8D. 45, FC
        inc     dword [eax]                             ; 0034 _ FF. 00

[Ancient Dragon]

So MinGW produces the same code too. But you can't compare the results of vc++2010 with yours because the c programs are not the same. The program I posted uses a pointer while yours just uses an integer. Try making your code use a pointer and see the result asm code.

I changed mine to use an int instead of a pointer and the compiler produced the same code as before, but this time added 1. It did not use the inc assembly operator.

[Auraomega]

Using your exact code produces more or less the same output assembly as VC++10:

lea     eax, [ebp-2CH]                          ; 0053 _ 8D. 45, D4
        add     dword [eax], 4                          ; 0056 _ 83. 00, 04
        lea     eax, [ebp-2CH]                          ; 0059 _ 8D. 45, D4
        add     dword [eax], 4                          ; 005C _ 83. 00, 04
        lea     eax, [ebp-2CH]                          ; 005F _ 8D. 45, D4
        add     dword [eax], 4                          ; 0062 _ 83. 00, 04

I chose not to use a pointer though as the OP simply assigned a value. In the case of a pointer you would be adding 4 as opposed to 1 which makes inc the slower of the 2 as it would be required 4 times as often.

[Ancient Dragon]

If no optimisation took place, that would be the case, yes.

I think we have proven, for two compilers that statement is incorrect. The only difference between p++ and p = p + 1 is personal preference (or company coding standards).

[Auraomega]

I have to agree with that, in the future I'll be checking on VC++/GCC as well as Mingw, I just (wrongly) assumed that all compilers would compile simple increments the same :P

[priyanka.js28]

v have different opinions here...!!:)
stilll hvnt got the answr

[Ancient Dragon]

Of course you have the answer. The answer is: it may be compiler dependent. But for MinGW and VC++ 2010 express there is no difference in speed.

[Auraomega]

And I've just confirmed the same with GCC, which probably covers 3 of the most popular compilers.

[Narue]

>I just (wrongly) assumed that all compilers would compile simple increments the same
As with many compiler specifics, it's not quite that simple. Depending on the target processor, different instructions may be deemed more efficient. So you'll see compilers favoring for example add over inc, or lea over both add and inc. The bias can change even within the same processor family. So the machine code itself may vary depending on hardware targets.

In terms of which of ++x , x++ , x+=1 , and x=x+1 is faster, you're talking about one of the most basic of basic optimizations (even Ritchie's first C compiler did this). Much like I would expect local variable allocation along with the stack frame regardless of scope rather than when execution enters each scope, I would expect all of the above (in isolation) to produce identical instructions even with optimization disabled.

So let's look at the questions I saw pop up in the thread:

• Q: Which is faster, ++x or x+=1 ?
  A: On any decent compiler there's no difference, but only when the expressions are taken in isolation. As part of a larger expression, there's more to consider. However, the usual guideline of "mind your own business and let the compiler handle micro-management of expressions" applies. It's better at it than you are anyway.
• Q: Will the above compile to the same machine code on my compiler?
  A: It's very likely, unless you have a compiler that aggressively refuses to optimize and interprets the C code as literally as possible. Barring student attempts at a toy compiler, I have yet to see any that do this.
• Q: Will all compilers compile the above to the same machine code?
  A: That's very unlikely. The actual machine code chosen by the compiler depends on a lot of things, and it's unreasonable to expect multiple compilers to make the same choices. However, it's not unreasonable to expect a suitably efficient choice for the situation to be selected. Despite what these "which is faster" questions imply, compiler writers are actually very good at squeezing out as much dead weight as possible.

[Saustin_Ben]

Honestly, it wouldn't really matter which you do, because it would make EXTREMELY small changes even if you did numbers like from 0 to 2147483647! You wouldn't notice a difference really. So I'd say why would you even want to know which is faster?

[SaiBalaji]

All conditions will execute in same manner.But P++ and ++P are more easier to write than p=p+1 and p+=1