• Advertisement
Sign in to follow this  

Which is the fastest?

This topic is 4252 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Is it Test1 or Test2, please explain why... Test1:
int a,b,c;
a=b+c;
Test2:
int a,b,c;
b+=c;
a=b;
(Where it is a empty space there should be a <plus>)

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by darkforest
Is it Test1 or Test2, please explain why...

Test1:
int a,b,c;
a=b+c;

Test2:
int a,b,c;
b+=c;
a=b;


(Where it is a empty space there should be a <plus>)

Does it really matter?
There might be some mundance differences in performance between the two, but will this micro optimiztion will really going to be any benefitial for you?
I would recommend you to choose the one that makes it more east to understand what it does.

Share this post


Link to post
Share on other sites
Test1, because it has less characters in source code, that is why I can type it faster than Test2.

Share this post


Link to post
Share on other sites
The compiler will compile these two into the same code, anyways. Something like
mov   eax,    ; eax = b
add eax, [c] ; eax += c
mov [a], eax ; a = eax
Since it doesn't have much other options (on the x86, that is).

You should use a = b + c; since that is a bit more readable than b += c; a = b;.

[Edit]: Test2 modifies the variable b, which may not be what you exactly want. You've got the same value in two variables then -- which may be a bit redundant, if you do not need to keep the original b's value.

Share this post


Link to post
Share on other sites
Since the example is so trivial, any compiler worth being called a compiler with todays standards will produce the same code. Why? Because the end result of the two codes are the same; after the code is executed, a is the sum of b and c, and that is what the compiler is generating code for. Same result, same code.

The only possible exception is the issue Oxyd presented; the fact that you modify b in Test2 could make a difference, but only if you use b later in the program. If you don't, the compiler will ignore the fact that you use b as a temporary storage for the sum.

Todays compilers are not stupid. They will catch something trivial like this and make the best out of it. You write the code in the way you can read it best, and the compiler will make machine code that reproduces the end result. It will not make a one to one mapping between source code statements and machine code.

Share this post


Link to post
Share on other sites
Why do you care? Use Test1 unless you needs to add a to b anyway. What will happen in the first is something like this (where the first operand is the destination, and we ignore registers since we are just trying to show the instructions):

mov a, b
add a, c


While Test2 will be something like this.

add b, c
mov b, a


I doubt there will be a big difference, except b is modified in the second.

Share this post


Link to post
Share on other sites
Quote:
Original post by darkforest
Is it Test1 or Test2, please explain why...

Test1:
int a,b,c;
a=b+c;

Test2:
int a,b,c;
b+=c;
a=b;


(Where it is a empty space there should be a <plus>)
Speed is absolutely irrelevant. The two have different behaviours. The second one modifies the value of b whereas the first one does not. Without furthur code to place this in context, the question is meaningless.

Rules of Optimisation:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
- M.A. Jackson

Share this post


Link to post
Share on other sites
As iMalk says, the two have different behaviour, so there's not much point in comparing them. But, to answer your question, Test1 has 1 addition and 1 assignment, whereas Test2 has 1 addition and 2 assignments, so Test1 faster.

Share this post


Link to post
Share on other sites
I'm pretty sure both tests would put you in the realm of undefined behaviour, I think you have more to worry about than optimization. ;)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement