Skip to main content
gamedev.net
🔒 Locked

optimization?

Started by DarkZoulz Aug 7, 2006 at 8:28 PM 13 replies 1.5k views
Original Post
DarkZoulz
DarkZoulz
Which of the following is the fastest? 


int a, b, c;

b += c;
a = b;
or 


int a, b, c;

a = b + c;
I'd say alternative 2. But if you asked me why I couldn't give you a direct answer. It just "feels" better. Also, if you exchanged the int's with a fully implemented vector class (overloaded operators etc) that is as optimized as possible. Which would be faster then? A friend gave me this to ponder on.
SiCrane
SiCrane
Micro-fragments of code are pretty meaningless to examine for performance. The nice thing about optimizing compilers is the ability to extract instruction level parallelism from the input code set. Chances are those variables will be fed into different expressions which will then be fed into other expressions, which will then be diced, mixed and blended in a number of happy different ways. And the ending machine code will bear the same resemblence to the input source code as spaghetti before and after being run over by a steam roller.
DarkZoulz
DarkZoulz
Quote:
Original post by Roboguy
Those two bits of code don't do the same thing. But, anyway, as SiCrane said, it doesn't matter.


They don't? But the result is the same? First one: adds 'c' to 'b' and then sets 'a' to 'b'. The second: sets 'a' to 'b + c'. Maybe the += operator is slow? (or slower)

I know this tiny optimization if most likely insignificant, but would be fun to know.
Deyja
Deyja
What is the value of b after the first piece of code?

After the second?

See, they don't do the same thing.
DarkZoulz
DarkZoulz
Quote:
Original post by Deyja
What is the value of b after the first piece of code?

After the second?

See, they don't do the same thing.


Aha, now I see what you mean. The first code alters the value of 'b', while the second does not. Hadn't thought of that.
Mike Bossy
Mike Bossy
The thing to keep in mind around performance is that compilers are really good at optimizing. The C++ compiler that comes with Visual Studio 2005 will beat almost anyone trying to optimize low-level code like additions themselves. Keep your optimizations to the algorithmic level unless you know that you have a perf problem.
iMalc
iMalc
This is IDENTICAL to some thread from about a month or two ago, if someone can find that thread then I suggest linking to that one and then closing this one.

[dead]That'll save us all from repeating what we wrote last time![dead]
JohnBolton
JohnBolton
Quote:
Original post by DarkZoulz
Quote:
Original post by Roboguy
Those two bits of code don't do the same thing. But, anyway, as SiCrane said, it doesn't matter.

They don't? But the result is the same? First one: adds 'c' to 'b' and then sets 'a' to 'b'. The second: sets 'a' to 'b + c'. Maybe the += operator is slow? (or slower)
I know this tiny optimization if most likely insignificant, but would be fun to know.


The compiler is going to produce exactly the same output in both cases (assuming you don't care about the value in b). If it doesn't, it is because the surrounding code affects optimization or the operators have been overloaded, and you can't determine which one is faster with only the code you provided.

So, either they are exactly the same, or there is no way to tell.
John BoltonLocomotive Games (THQ)Current Project: Destroy All Humans (Wii). IN STORES NOW!
DarkZoulz
DarkZoulz
How about this:

D3DXVECTOR3 a, b, c;// alt 1b += c;a = b;// alt 2a = b + c;


Why is alt 1 faster than 2? I've tried it. Testing each alternative in a for-loop of 10,000,000 cycles. I used GetTickCount() for the timing.

Alt 1: ~460 ms
Alt 2: ~840 ms
ToohrVyk
ToohrVyk
operator+ returns by value, requiring a temporary variable. Also, since the compiler cannot assume that, for vectors, the two statements are equivalent, it cannot optimize the second in terms of the first.

As a side note, + on non-native types (such as vectors) is generally implemented as:

T operator+(const T & a, const T & b) {  T c(a);  return c += b;}


Hence the additional work performed.
Blog — Facebook
Sharlin
Sharlin
Hmm... AFAIK the suggested way of writing operator+ (and others) is as below, and the reason is exactly that in this case, the compiler is allowed to do NRVO and create the return value in place, thus eliminating a copy. Of course, DirectX might not follow this idiom, or optimizations might not have been enabled... 

T operator+(const T & a, const T & b) {  T c(a);  c += b;  return c;}
Evil Steve
Evil Steve
Quote:
Original post by DarkZoulz
How about this:

*** Source Snippet Removed ***

Why is alt 1 faster than 2? I've tried it. Testing each alternative in a for-loop of 10,000,000 cycles. I used GetTickCount() for the timing.

Alt 1: ~460 ms
Alt 2: ~840 ms
What code did you use to profile? Was it release mode? How are you making sure the variables aren't optimised away? They should have pretty much identical performance with a release build with full optimisation.

EDIT:
Quote:
Original post by Sharlin
Hmm... AFAIK the suggested way of writing operator+ (and others) is as below, and the reason is exactly that in this case, the compiler is allowed to do NRVO and create the return value in place, thus eliminating a copy. Of course, DirectX might not follow this idiom, or optimizations might not have been enabled...

From d3dx9math.inl:
D3DXINLINE D3DXVECTOR3D3DXVECTOR3::operator + ( CONST D3DXVECTOR3& v ) const{    return D3DXVECTOR3(x + v.x, y + v.y, z + v.z);}D3DXINLINE D3DXVECTOR3&D3DXVECTOR3::operator += ( CONST D3DXVECTOR3& v ){    x += v.x;    y += v.y;    z += v.z;    return *this;}



With full optimisations on, the code will be exactly the same.
DarkZoulz
DarkZoulz
Ah, I see. I was compiling in debug mode.

Thanks for the info!

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.