Ad:

C++ Discussion Thread
Marked Solved
Views: 1878

Feb 5th, 2008

compound operator proving efficiency

Expand Post »

Hi all,

I've been searching for hours but i can't find any solutions so i hope someone can help...

Is there any way of proving that the += operator is more efficient than the + operator...

i.e. A += B instead of A = A + B

I'm hoping to use code to see how much overhead is being saved.

thanks in advance,

John Riley

johnRiley

Reputation Points: 10

Solved Threads: 0

Newbie Poster

Offline

7 posts
since Feb 2008

Permalink

Feb 5th, 2008

Re: compound operator proving efficiency

>Is there any way of proving that the += operator is more efficient than the + operator...
Sure. Look at it and say "Hey, A is being evaluated twice with the + operator but only once with the += operator" and "Hey, A + B is probably making a temporary copy".

Narue

Administrator

Reputation Points: 6442

Solved Threads: 1393

Bad Cop

Offline

11,807 posts
since Sep 2004

Permalink

Feb 5th, 2008

Re: compound operator proving efficiency

It is more efficient and i know that the standard operator assignment is being performed on a temporary value.

My question is, is there a way of proving it with code? Otherwise how do we know for sure.

johnRiley

Reputation Points: 10

Solved Threads: 0

Newbie Poster

Offline

7 posts
since Feb 2008

Permalink

Feb 5th, 2008

Re: compound operator proving efficiency

>My question is, is there a way of proving it with code?
Well, that's different from your original question, isn't it? Why not perform the operations a few billion times and see which one takes longer?

C++ Syntax (Toggle Plain Text)
#include <ctime>
#include <climits>
#include <iostream>
 
template <typename T>
double runassignadd ( unsigned long n )
{
  T a = T();
  T b = T();
  std::clock_t start = std::clock();
 
  for ( unsigned long i = 0; i < n; i++ )
    a += b;
 
  return ( (double)std::clock() - start ) / CLOCKS_PER_SEC;
}
 
template <typename T>
double runadd ( unsigned long n )
{
  T a = T();
  T b = T();
  std::clock_t start = std::clock();
 
  for ( unsigned long i = 0; i < n; i++ )
    a = a + b;
 
  return ( (double)std::clock() - start ) / CLOCKS_PER_SEC;
}
 
int main()
{
  std::cout<<"A += B    -- "<< runassignadd<int> ( UINT_MAX ) <<'\n';
  std::cout<<"A = A + B -- "<< runadd<int> ( UINT_MAX ) <<'\n';
}
#include <ctime>
#include <climits>
#include <iostream>

template <typename T>
double runassignadd ( unsigned long n )
{
  T a = T();
  T b = T();
  std::clock_t start = std::clock();

  for ( unsigned long i = 0; i < n; i++ )
    a += b;
  
  return ( (double)std::clock() - start ) / CLOCKS_PER_SEC;
}

template <typename T>
double runadd ( unsigned long n )
{
  T a = T();
  T b = T();
  std::clock_t start = std::clock();

  for ( unsigned long i = 0; i < n; i++ )
    a = a + b;
  
  return ( (double)std::clock() - start ) / CLOCKS_PER_SEC;
}

int main()
{
  std::cout<<"A += B    -- "<< runassignadd<int> ( UINT_MAX ) <<'\n';
  std::cout<<"A = A + B -- "<< runadd<int> ( UINT_MAX ) <<'\n';
}

>Otherwise how do we know for sure.
Don't put too much weight on empirical tests for making a general statement. There are often unknowns that skew the result and depend on the machine you test with, the code you use, and so on.

Last edited by Narue; Feb 5th, 2008 at 4:41 pm.

Narue

Administrator

Reputation Points: 6442

Solved Threads: 1393

Bad Cop

Offline

11,807 posts
since Sep 2004

Permalink

Feb 5th, 2008

Re: compound operator proving efficiency

Short of examining the object code created, probably no definitive answer. It may be compiler dependent.

In a brute force approach, run the two operations in a verrrrry big loop, time the differences. I just tried this:

C++ Syntax (Toggle Plain Text)
#include <iostream>
#include <cstdlib>
#include <ctime>
 
using namespace std;
 
int main() 
{
   int a = 10;
   int b = 6;
   unsigned int i;
   int j;
 
   clock_t   start_time, end_time;
 
   start_time = clock( );
 
   for( j = 0; j < 10; j++ )
      for( i = 0; i < 4000000000 ; i++)
      {
         a = 10;
         a = a + b;
      }
 
   end_time = clock( );
   cout << "time: " 
         << (double)(end_time - start_time)/ CLOCKS_PER_SEC << endl << endl;
 
   cout << start_time << '\t' << end_time << endl;
 
    return 0;
}// end of main
#include <iostream>
#include <cstdlib>
#include <ctime>

using namespace std;

int main() 
{
   int a = 10;
   int b = 6;
   unsigned int i;
   int j;

   clock_t   start_time, end_time;

   start_time = clock( );

   for( j = 0; j < 10; j++ )
      for( i = 0; i < 4000000000 ; i++)
      {
         a = 10;
         a = a + b;
      }

   end_time = clock( );
   cout << "time: " 
         << (double)(end_time - start_time)/ CLOCKS_PER_SEC << endl << endl;

   cout << start_time << '\t' << end_time << endl;

    return 0;
}// end of main

changing the a = a + b; to the += version in a second test. Running on a 3.2GHz Pentium D, the timings were:
a = a + b 109.83
a += b 109.143

Hmmm, is there any significant, practical difference? I think not. Remember, that was 40 billion iterations.

YMMV
Val

vmanes

Reputation Points: 1268

Solved Threads: 228

Posting Virtuoso

Offline

1,895 posts
since Aug 2007

Permalink

Feb 6th, 2008

Re: compound operator proving efficiency

I do like the idea of timing the different assignments. What about actually changing or overloading the += operator? any ideas or suggestions?

does anyone know which header file holds the += operator code?

My apologies to Narue... my original question was different but i meant no offense.

johnRiley

Reputation Points: 10

Solved Threads: 0

Newbie Poster

Offline

7 posts
since Feb 2008

Permalink

Feb 6th, 2008

Re: compound operator proving efficiency

> Hmmm, is there any significant, practical difference?
> I think not. Remember, that was 40 billion iterations.

for standard types like int or double, it would not make any difference. the compiler knows everything about these types and can see that
a = a + b ; and a += b ; are equivalent and generate identical (optimized) code.

the case could be different for user defined types; for one the overloaded + or += operators may not be inline and the compiler cannot make any assumptions about the equivalence between
a = a + b ; and a += b ; . if the operatos are inline, a good compiler can still optimize; even in this case, avoiding the creation of anonymous temporaries can improve performance.

c++ Syntax (Toggle Plain Text)
int func_int_plus( int a, int b )
{
  return a = a + b ;
}
 
int func_int_plus_assign( int a, int b )
{
  return a += b ;
}
 
struct A
{ 
  A( int xx, int yy ) : x(xx), y(yy) {}
  A operator+ ( const A& that ) const 
  { return A( x+that.x, y+that.y ) ; }
  A& operator+= ( const A& that ) 
  { x += that.x ; y += that.y ; return *this ; }
  int x ;
  int y ;
};
 
A func_A_plus( A a, A b )
{
  return a = a + b ;
}
 
A func_A_plus_assign( A a, A b )
{
  return a += b ;
}
 
A& func_A_plus_assign_byref( A& a, const A& b )
{
  return a += b ;
}
int func_int_plus( int a, int b )
{
  return a = a + b ;
}

int func_int_plus_assign( int a, int b )
{
  return a += b ;
}

struct A
{ 
  A( int xx, int yy ) : x(xx), y(yy) {}
  A operator+ ( const A& that ) const 
  { return A( x+that.x, y+that.y ) ; }
  A& operator+= ( const A& that ) 
  { x += that.x ; y += that.y ; return *this ; }
  int x ;
  int y ;
};

A func_A_plus( A a, A b )
{
  return a = a + b ;
}

A func_A_plus_assign( A a, A b )
{
  return a += b ;
}

A& func_A_plus_assign_byref( A& a, const A& b )
{
  return a += b ;
}

>c++ -O3 -S -fomit-frame-pointer operator.cc
an extract of the relevant parts of the assembly generated (gcc 4.2.3):

C++ Syntax (Toggle Plain Text)
    .file    "operator.cc"
/////////////////////////////////
_Z13func_int_plusii:
.LFB2:
    movl    8(%esp), %eax
    addl    4(%esp), %eax
    ret
.LFE2:
//////////////////////////////////
_Z20func_int_plus_assignii:
.LFB3:
    movl    8(%esp), %eax
    addl    4(%esp), %eax
    ret
.LFE3:
//////////////////////////////////
_Z11func_A_plus1AS_:
.LFB9:
    pushl    %ebx
.LCFI0:
    movl    8(%esp), %ebx
    movl    12(%esp), %ecx
    addl    16(%esp), %ebx
    addl    20(%esp), %ecx
    movl    %ecx, %edx
    movl    %ebx, %eax
    popl    %ebx
 output   ret
//////////////////////////////////
_Z18func_A_plus_assign1AS_:
.LFB10:
    pushl    %ebx
.LCFI1:
    movl    12(%esp), %ecx
    movl    8(%esp), %ebx
    addl    16(%esp), %ebx
    addl    20(%esp), %ecx
    movl    %ecx, %edx
    movl    %ebx, %eax
    popl    %ebx
    ret
.LFE10:
//////////////////////////////////
_Z24func_A_plus_assign_byrefR1ARKS_:
.LFB11:
    movl    4(%esp), %eax
    movl    8(%esp), %ecx
    movl    (%ecx), %edx
    addl    %edx, (%eax)
    movl    4(%ecx), %edx
    addl    %edx, 4(%eax)
    ret
.LFE11:
//////////////////////////////////
    .file    "operator.cc"
/////////////////////////////////
_Z13func_int_plusii:
.LFB2:
    movl    8(%esp), %eax
    addl    4(%esp), %eax
    ret
.LFE2:
//////////////////////////////////
_Z20func_int_plus_assignii:
.LFB3:
    movl    8(%esp), %eax
    addl    4(%esp), %eax
    ret
.LFE3:
//////////////////////////////////
_Z11func_A_plus1AS_:
.LFB9:
    pushl    %ebx
.LCFI0:
    movl    8(%esp), %ebx
    movl    12(%esp), %ecx
    addl    16(%esp), %ebx
    addl    20(%esp), %ecx
    movl    %ecx, %edx
    movl    %ebx, %eax
    popl    %ebx
 output   ret
//////////////////////////////////
_Z18func_A_plus_assign1AS_:
.LFB10:
    pushl    %ebx
.LCFI1:
    movl    12(%esp), %ecx
    movl    8(%esp), %ebx
    addl    16(%esp), %ebx
    addl    20(%esp), %ecx
    movl    %ecx, %edx
    movl    %ebx, %eax
    popl    %ebx
    ret
.LFE10:
//////////////////////////////////
_Z24func_A_plus_assign_byrefR1ARKS_:
.LFB11:
    movl    4(%esp), %eax
    movl    8(%esp), %ecx
    movl    (%ecx), %edx
    addl    %edx, (%eax)
    movl    4(%ecx), %edx
    addl    %edx, 4(%eax)
    ret
.LFE11:
//////////////////////////////////

vijayan121

Reputation Points: 1159

Solved Threads: 285

Posting Virtuoso

Offline

1,606 posts
since Dec 2006

This thread is solved

Either the thread starter or a moderator has marked this thread as solved. You can most likely trust the responses and answers given. There is most likely no reason for any further responses to be posted here. If you have a related question, please start a new thread in this forum instead.

This thread is more than three months old

No one has posted to this discussion for at least three months. Please let old threads die and do not reply to them unless you feel you have something new and valuable to contribute that absolutely must be added to make the discussion complete. Otherwise, please start a new thread in this forum instead.

Previous Thread in C++ Forum Timeline: Which C++ complier to use

Next Thread in C++ Forum Timeline: Input operator overloading

DaniWeb Message

Cancel Changes

User Name
Password