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. )
Seems brewbuck thinks the same thing. Déjà vu.
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
Last edited by Cactus_Hugger; 05-31-2007 at 03:11 PM.
long time; /* know C? */
Unprecedented performance: Nothing ever ran this slow before.
Any sufficiently advanced bug is indistinguishable from a feature.
Real Programmers confuse Halloween and Christmas, because dec 25 == oct 31.
The best way to accelerate an IBM is at 9.8 m/s/s.
recursion (re - cur' - zhun) n. 1. (see recursion)
well,
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.Code:mov eax , y add x , eax
however, if you intend to use x in the next operation thusly -
you could optimize it like so :Code:x += y; x += z; x += w;
Code:mov eax , x add eax , y add eax , z add eax , w mov x , eax
Last edited by abachler; 05-31-2007 at 03:20 PM.
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.
takes 3 cyclesCode:mov eax , x add eax , ebx mov ecx , y add edx , ebx
takes 2 cyclesCode:add edx , ebx mov eax , x add eax , ebx mov ecx , y
both sequences produce the same result and execute the same instructions, only the order is different
Last edited by abachler; 05-31-2007 at 04:48 PM.
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.*
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
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
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).
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.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Error: cannot implicitly convert from double* to double.
The two implementations are identical.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 calls are identical too. What is done with the return value (= or +=) is of no concern to the function.which is call as
[code]
z += myFunction(a,b,c);
[code]
You pass the same parameters. At least they have the same names.The problem itself is set up differently for each function. While the input parameters are different,
No, that is not a difference of the implementations. That's a difference of what you're doing with the return value.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).
I'm afraid you're not making any sense.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
Sorry that should be
andCode:double *myFunction(double a, double b, double c){ double *z; z = a*b + c return z; }
I'm simply trying to propose a way that y = x and y += x could yield the same value.Code:double *myFunction(double d, double e, double f){ double *z; z = d*e+f return z; }
Last edited by thetinman; 06-05-2007 at 08:08 AM. Reason: make more literal
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.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law