Which Operation is Faster "=" or "+=" ?

I have two operations. The value of "x" is already set to some value. One of the operations is

Code:

---

x =  y

---

and the other is

Code:

---

x +=  y

---

Is one a tiny bit faster than the other? My guess is that the first one is faster, but I'm not certain. Is the speed exactly the same?

Yes, one is likely to be a tiny bit faster than the other.

Now whether it's always the same answer is much harder to say.

One thing is for sure, it's hardly ever going to matter to you.

They have a different meaning. Why do you ask?

It depends on the definitions of x & y, the code surrounding the usage of them, and the definitions of operator = and operator += for the types of x & y.

If the answer were ever as simple as a is faster than b (and they do the same thing) then we wouldn't have b.

Besides, chances are that your compiler will optimize it for you and you really shouldn't start optimizing before you have a bottleneck in your program. Not to mention that such little changes in your program couldn't make a huge difference.

Quote:

---

Originally Posted by thetinman

I have two operations. The value of "x" is already set to some value. One of the operations is

Code:

---

x =  y

---

and the other is

Code:

---

x +=  y

---

Is one a tiny bit faster than the other? My guess is that the first one is faster, but I'm not certain. Is the speed exactly the same?

---

As others have pointed out, the question does not compare apples and apples. If you meant to compare

Code:

---

x = x + y;

---

with

Code:

---

x += y;

---

Then there is a difference. In C standardese it is

Quote:

---

A compound assignment of the form E1 op= E2 differs from the simple assignment expression E1 = E1 op (E2) only in that the lvalue E1 is evaluated only once.

---

Whether or not one is faster may or may not be true on a given implementation.

Of course, all this may be moot in C++ if it is not built-in types.

as said, they are different in meaning. If you wanna which is faster as you say, you would considering using profiler

Quote:

---

Originally Posted by Dave_Sinkula

As others have pointed out, the question does not compare apples and apples. If you meant to compare

Code:

---

x = x + y;

---

with

Code:

---

x += y;

---

Then there is a difference. In C standardese it isWhether or not one is faster may or may not be true on a given implementation.

Of course, all this may be moot in C++ if it is not built-in types.

---

What's wrong with comparing apples and oranges? I could ask a simple question such as "Which one has more fiber?" or "Which has more vitamin C?"

I thought maybe there would be some theoretical answer to this, for example, one operation requires two reads, one add, and one write, and the other operation only requires one read and one write.

One operation does an assignment. The other does addition and assignment.

It's just unusual to question which one is faster when they do different things, since normally the point of identifying the faster one is to choose it when both options are possible. Since these two things do different things, there isn't as much reason to identify which is faster.

Assuming x and y are ints... the assembly instructions would be something like this on an x86 processor:

For x = y;

Code:

---

mov eax, y
mov x, eax

---

For x += y; (or even x = x + y)

Code:

---

mov eax, x
add eax, y
mov x, eax

---

Theory can go deeper than that.

With a simple assignment, and nothing else to go on (context), the optimizer could evaporate the assignment into nothing.

For example, say the purpose was to preserve the original y and operate upon x as a temporary local value. Depending on context, the compiler might not need to bother.

Like other posters point out, the type is an all important notion of this context. If x & y are objects, these two operator overloads (at least += must exist), must be consulted to offer any meaningful answer.

Assuming an atomic primitive, and further assuming that the context of the code is such that the compiler doesn't optimize the assignment into oblivion, the assignment is a simple move, as MacGyver has pointed out.

In the increment version, while there is another step in the assembler, it may depend on the processor's design & RAM as to whether that actually takes longer in real time.

It's instructive to try examples like this on various CPU targets and see how there are times when speed is affected as much by ancillary system components that anything we can do it code.

Quote:

---

Originally Posted by MacGyver

Assuming x and y are ints... the assembly instructions would be something like this on an x86 processor:

---

Actually, on x86 the CPU can add directly into a memory location, so the x += y code would (or at least could) look like:

Code:

---

mov eax, y
add x, eax

---

I'd wager that the two are identical in speed, at least on x86, if you assume perfect cache behavior.

And all that is working under the assumption that x and y are not held in registers already.

Either one could be faster; it depends on the types of x and y, the surrounding code, the compiler, and the processor. Looking at those statements as if they will map to particular sequences of machine code instructions is a mistake.

Quote:

---

Originally Posted by MacGyver

For x += y; (or even x = x + y)

Code:

---

mov eax, x
add eax, y
mov x, eax

---

---

Actually I think it would be more like:
for x += y;

Code:

---

mov eax , y
add x , eax

---

:rolleyes: What happens when you ask a board of programmers such a question. Besides, who said anything about an x86 processor. I've done more assembly elsewhere. (Usually because I couldn't use C, but hey. :p)

Quote:

---

Originally Posted by abachler

Actually I think it would be more like:
for x += y;

Code:

---

mov eax , y
add x , eax

---

---

Seems brewbuck thinks the same thing. Déjà vu.

Quote:

---

Originally Posted by brewbuck, something like 2 hours earlier ;)

Actually, on x86 the CPU can add directly into a memory location, so the x += y code would (or at least could) look like:

Code:

---

mov eax, y
add x, eax

---

I'd wager that the two are identical in speed, at least on x86, if you assume perfect cache behavior.

---

My x86 instruction sheet doesn't have speed listed... could not two processors differ in the # of cycles needed? (Between AMD & Intel?)

Edit: The multiquote button works across pages, very impressive.

Edit: According to this page, the clock cycles, on a 486 (best it had...) I believe it works out to:

Code:

---

mov eax, x  ; 1
add eax, y  ; 2
mov x, eax  ; 1
            ; Total = 4

mov eax, y  ; 1
add x, eax  ; 3
            ; Total = 4

---

well,

Code:

---

mov eax , y
add x , eax

---

would take 2 clock cycles (pentium era cpus execute most ops in 1 cycle), since the add is data dependant on the mov, so the pipline stalls at least a little bit. however, since it would take fewer memory locations, it woudl reduce cache useage, and so be faster by potentially reducing cache delays.

however, if you intend to use x in the next operation thusly -

Code:

---

x += y;
x += z;
x += w;

---

you could optimize it like so :

Code:

---

mov eax , x
add eax , y
add eax , z
add eax , w
mov x , eax

---

Quote:

---

Originally Posted by Cactus_Hugger

My x86 instruction sheet doesn't have speed listed... could not two processors differ in the # of cycles needed? (Between AMD & Intel?)

---

Nah. Simple integer moves and additions have always taken only a single cycle, again, assuming perfect cache behavior.

Most sheets dont list the opcode timings anymore because they wouldnt be accurate in any case. The timing of an instruction on a pipelined cpu is too dependant on the instructions before and after it for such a figure to be meaningful. what with out-of-order execution, branch prediction, tentative execution, it becomes pointless.

Code:

---

mov eax , x
add eax , ebx
mov ecx , y
add edx , ebx

---

takes 3 cycles

Code:

---

add edx , ebx
mov eax , x
add eax , ebx
mov ecx , y

---

takes 2 cycles

both sequences produce the same result and execute the same instructions, only the order is different

Quote:

---

Originally Posted by thetinman

What's wrong with comparing apples and oranges? I could ask a simple question such as "Which one has more fiber?" or "Which has more vitamin C?"

---

Because any answer is specious at best, even comparing equivalent operations. With regard to the language, "Which is faster?" questions have no merit.

With regard to a particular implementation, on a particular OS, with particular options, at a given moment in time is what you are left with. But you'd be surprised by "silly" advice from the past that was once "common knowledge", and any result of this query is likely to be viewed as "silly" in the future.

Both have the diffrent meanings
while x=y; is assigning the value of y to x and x+=y; transforms to x=x+y;
both have no relation whatsoever.


May i ask what was the purpose of asking this question?
Did you mean to ask which one is faster between these two?
x=x+y;
x+=y;


-----------------
http://learning-computer-programming.blogspot.com

Quote:

---

Originally Posted by Dave_Sinkula

Because any answer is specious at best, even comparing equivalent operations. With regard to the language, "Which is faster?" questions have no merit.

With regard to a particular implementation, on a particular OS, with particular options, at a given moment in time is what you are left with. But you'd be surprised by "silly" advice from the past that was once "common knowledge", and any result of this query is likely to be viewed as "silly" in the future.

---

Are you sure? Wouldn't

Code:

---

y = powf(x,2);

---

always be slower than

Code:

---

y = x*x;

---

on all platforms, OSs, and in all languages? I suppose with optimation, or certain architectures, they could be the same speed, but the former will never be faster than the later. I could therefore conclude that, if speed is an issue, I should definitely use the later.

Quote:

---

Originally Posted by Daved

One operation does an assignment. The other does addition and assignment.

It's just unusual to question which one is faster when they do different things, since normally the point of identifying the faster one is to choose it when both options are possible. Since these two things do different things, there isn't as much reason to identify which is faster.

---

This question looks strange to many people so I propose an example. Here's one function

Code:

---

double *myFunction(double a, double b, double c){
  double z;
  z = a*b + c
  return z;
}

---

which is called as
[code]
z = myFunction(a,b,c);
[code]

Code:

---

double *myFunction(double a, double b, double c){
  double z;
  z = b*c + a;
  return z;
}

---

which is call as
[code]
z += myFunction(a,b,c);
[code]

The problem itself is set up differently for each function. While the input parameters are different, the answer z, is the same. Speaking in terms of efficiency of code, the only difference between the two implementations is that one uses z = myFunction(a,b,c), while the other uses z += myFunction(a,b,c).

But that's not really a question in regard to the language.

But had you used pow(x, 2), I know some systems where this will probably really optimize down to x*x.

Quote:

---

Originally Posted by thetinman

This question looks strange to many people so I propose an example. Here's one function

Code:

---

double *myFunction(double a, double b, double c){
  double z;
  z = a*b + c
  return z;
}

---

---

Error: cannot implicitly convert from double* to double.

Quote:

---

which is called as
[code]
z = myFunction(a,b,c);
[code]

Code:

---

double *myFunction(double a, double b, double c){
  double z;
  z = b*c + a;
  return z;
}

---

---

The two implementations are identical.

Quote:

---

which is call as
[code]
z += myFunction(a,b,c);
[code]

---

The two calls are identical too. What is done with the return value (= or +=) is of no concern to the function.

Quote:

---

The problem itself is set up differently for each function. While the input parameters are different,

---

You pass the same parameters. At least they have the same names.

Quote:

---

the answer z, is the same. Speaking in terms of efficiency of code, the only difference between the two implementations is that one uses z = myFunction(a,b,c), while the other uses z += myFunction(a,b,c).

---

No, that is not a difference of the implementations. That's a difference of what you're doing with the return value.

I'm afraid you're not making any sense.

Quote:

---

Originally Posted by CornedBee

Error: cannot implicitly convert from double* to double.


The two implementations are identical.


The two calls are identical too. What is done with the return value (= or +=) is of no concern to the function.


You pass the same parameters. At least they have the same names.


No, that is not a difference of the implementations. That's a difference of what you're doing with the return value.

I'm afraid you're not making any sense.

---

Sorry that should be

Code:

---

double *myFunction(double a, double b, double c){
  double *z;
  z = a*b + c
  return z;
}

---

and

Code:

---

double *myFunction(double d, double e, double f){
  double *z;
  z = d*e+f
  return z;
}

---

I'm simply trying to propose a way that y = x and y += x could yield the same value.

The functions are still the same, just with different parameter names, and will still not compile: now you're trying to assign the result of a*b+c, which is a double, to a pointer to double.

And the only way y=x and y+=x yield the same value is if y is 0. The right side, where your function is, has nothing to do with it.

Quote:

---

Originally Posted by CornedBee

But that's not really a question in regard to the language.

But had you used pow(x, 2), I know some systems where this will probably really optimize down to x*x.

---

You have a good point, however, the reverse might not be true. In other words: x*x is unlikely to be deoptimized up to pow(x,2). Perhaps my question would be better put as, "Which is most likely to be faster, and why?"

But the rule of thumb is: either it's painfully obvious which one is faster even to inexperienced programmers (as in the pow(x, 2) vs x*x case) or even experienced programmers might guess incorrectly. And in any case, for single instructions, it's also nearly irrelevant.

In the end, whenever there is a question of performance, the first answer is "Run a profiler!". No other answers should be attempted until the profiling data can be analyzed.

plus if you have come down to the point where you try to optimize such a trivial thing, chances are your doing something horribly wrong somewhere else.

Quote:

---

Originally Posted by CornedBee

The functions are still the same, just with different parameter names, and will still not compile: now you're trying to assign the result of a*b+c, which is a double, to a pointer to double.

And the only way y=x and y+=x yield the same value is if y is 0. The right side, where your function is, has nothing to do with it.

---

Sorry, I'm not articulating this very well. Here is some code where += and = will produce the same result in many situations.

Code:

---

                        y = x;

---

and

Code:

---

                        y += m;

---

Quote:

---

Originally Posted by Shakti

plus if you have come down to the point where you try to optimize such a trivial thing, chances are your doing something horribly wrong somewhere else.

---

The problem is to understand the difference between various numerical methods.

Quote:

---

Sorry, I'm not articulating this very well. Here is some code where += and = will produce the same result in many situations.

Code:

---


                        y = x;

---

and

Code:

---


                        y += m;

---

---

Why do you think that? That would depend entirely on the values of x, y and m. Pick whichever makes sense.

Suppose you wanted to set y (initalized to 0) equal to x. Which would you do?

Code:

---

y = x;

---

Or

Code:

---

y += x;

---

I would choose the first, because then both me and others would understand what this code is meant to do.
I can't remember a single instance where I wondered: hm, should I do assignment or addition? - Eh, I'll pick whichever is faster.

Sorry tinman, but the point still stands. y = x and y += m do completely different things, so comparing which is faster makes little sense. Use the one that does what you want. If you want to add to y, use +=. If you want to ignore y's current value and assign to it, use =.

The only question that makes sense is this:

Code:

---

y = 0;
// x = ?
y = x;

---

versus:

Code:

---

y = 0;
// x = ?
y += x;

---

Those two code snippets do exactly the same thing (assuming normal addition semantics) only because y is 0 and adding x to 0 is the same as assigning x. However, in that case which version you use would depend on which is clearer given the context, not efficiency concerns.

Your question leaves out the y = 0, so it makes little sense. For example, if y is 5 and x is 10 you have this:

Code:

---

y = 5;
x = 10;
y = x;
// y is now 10.

---

versus:

Code:

---

y = 5;
x = 10;
y += x;
// y is now 15.

---

See... it doesn't matter which is faster, because they produce different results.

Quote:

---

Originally Posted by thetinman

Are you sure? Wouldn't

Code:

---

y = powf(x,2);

---

always be slower than

Code:

---

y = x*x;

---

on all platforms, OSs, and in all languages?

---

It's already been mentioned: no.

But this reminded me of the reverse:

Code:

---

#define ADDRESS 0x400

struct sType1
{
  unsigned char c;
  unsigned int  i;
} Object1 = {5,0};

struct sType2
{
  unsigned char a;
  unsigned char b;
  unsigned char d[50];
  unsigned int  e;
} Object2;

int foo(void)
{
  unsigned int addr1, addr2  = ADDRESS + (sizeof(Object2) * (Object1.c - 1));
  addr1  = Object1.c - 1; /* implicit cast of char */
  addr1 *= sizeof(Object2);
  addr1 += ADDRESS;
  return addr1 == addr2;
}

---

Find the [implementation] library function call(s) on the highlighted line.

Sounds like a lea x86 instruction could compute this.

If you are hinting at the multiply, then yes. It was on a platform that either did not have a multiply operation, or had only an 8-bit multiply -- I forget. The multiplication was implemented using a function call.