I have two operations. The value of "x" is already set to some value. One of the operations is
and the other isCode: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?Code:x += y
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.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
They have a different meaning. Why do you ask?
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
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.
My homepage
Advice: Take only as directed - If symptoms persist, please see your debugger
Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"
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.
As others have pointed out, the question does not compare apples and apples. If you meant to compareOriginally Posted by thetinman
withCode:x = x + y;Then there is a difference. In C standardese it isCode:x += y;Whether or not one is faster may or may not be true on a given implementation.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.
Of course, all this may be moot in C++ if it is not built-in types.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
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.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
Are you sure? Wouldn't
always be slower thanCode:y = powf(x,2);
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.Code:y = x*x;
Last edited by thetinman; 06-05-2007 at 07:35 AM. Reason: Add stuff
It's already been mentioned: no.
But this reminded me of the reverse:
Find the [implementation] library function call(s) on the highlighted line.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; }
Last edited by Dave_Sinkula; 06-05-2007 at 09:46 PM. Reason: After a long struggle to find the right word.
7. It is easier to write an incorrect program than understand a correct one.
40. There are two ways to write error-free programs; only the third one works.*
as said, they are different in meaning. If you wanna which is faster as you say, you would considering using profiler
"C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg."-Bjarne Stroustrup
Nearing the end of finishing my 2D card game! I have to work on its 'manifesto' though <_<
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.
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.
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
which is called asCode:double *myFunction(double a, double b, double c){ double z; z = a*b + c return z; }
[code]
z = myFunction(a,b,c);
[code]
which is call asCode:double *myFunction(double a, double b, double c){ double z; z = b*c + a; return z; }
[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).
