Performance penalty for encapsulations ??

[Yuri Victorovich]

I have simple program which computes internal
product on large vector.
Whan the element of vector is "int" performance is
about 70% better than when I use class with single
field "int" in it and overload appropriate operators.

Does this indicate wakness of compiler or this is natural
for C++ ?

I compared with gcc-3.2 with -O3 optimization.

Yuri

----------code-----------------------------------------

#include <stdio.h>

class C_int {
public:
int i;
inline C_int() { }
inline C_int(int new_i) { i = new_i; }
inline C_int operator*(C_int i1) {
C_int ii(i*i1.i);
return (ii);
}
inline C_int operator+(C_int i1) {
C_int ii(i+i1.i);
return (ii);
}
inline void operator+=(C_in t i1) {
i += i1.i;
}
inline void operator=(int ii) { i = ii; }
// inline void operator(int)() { return (i); }
};

#define TYPE C_int // 1
//#define TYPE C_int // 2
#define SZ 30000000

TYPE v1[SZ];
TYPE v2[SZ];

int
main(int argc, const char *argv[]) {

{ // initialize
for (int i = 0; i < SZ; i++) {
v1[i] = i^0x010101 + 0x437785;
v2[i] = i^0x017132 + 0x245726;
}
}

TYPE res = 0;
{ // inner product
for (int i = 0; i < SZ; i++) {
res += v1[i] * v2[i];
}
}

// printf("res=%i\ n", res.i);
return (0);
}

[Kevin Goodsell]

Re: Performance penalty for encapsulations ??

Yuri Victorovich wrote:
[color=blue]
> I have simple program which computes internal
> product on large vector.
> Whan the element of vector is "int" performance is
> about 70% better than when I use class with single
> field "int" in it and overload appropriate operators.
>
> Does this indicate wakness of compiler or this is natural
> for C++ ?
>[/color]

There are a lot of possible contributors to the performance decrease. I
don't know how you are measuring the time, but note that you are
constructing 30000000 class instances, which is obviously going to take
some time. Did you include that in your timing?

Another likely issue is that you've reduced the compiler's ability to
optimize.

You can create pretty significant optimizations by using classes well,
but if you use them poorly all you do is complicate the compiler's job,
likely making the code less efficient.
[color=blue]
> I compared with gcc-3.2 with -O3 optimization.
>
> Yuri
>
> ----------code-----------------------------------------
>
> #include <stdio.h>
>
> class C_int {
> public:
> int i;
> inline C_int() { }[/color]

You don't need to say 'inline' here. Functions defined within the class
definition are always inlined.
[color=blue]
> inline C_int(int new_i) { i = new_i; }
> inline C_int operator*(C_int i1) {
> C_int ii(i*i1.i);
> return (ii);
> }
> inline C_int operator+(C_int i1) {
> C_int ii(i+i1.i);
> return (ii);
> }
> inline void operator+=(C_in t i1) {
> i += i1.i;
> }
> inline void operator=(int ii) { i = ii; }
> // inline void operator(int)() { return (i); }[/color]

If that was supposed to be a conversion to int you got it wrong.

operator int() { return i; }
[color=blue]
> };
>
> #define TYPE C_int // 1
> //#define TYPE C_int // 2
> #define SZ 30000000[/color]

Why macros? Macros are bad. Use typedef and const instead.
[color=blue]
>
> TYPE v1[SZ];
> TYPE v2[SZ];
>
> int
> main(int argc, const char *argv[]) {[/color]

I don't think this is a legal signature for main. According to the
standard, the second argument must be 'char *argv[]' or something
equivalent. I don't think adding 'const' is allowed.
[color=blue]
>
> { // initialize[/color]

What's with the extra redundant blocks?
[color=blue]
> for (int i = 0; i < SZ; i++) {
> v1[i] = i^0x010101 + 0x437785;
> v2[i] = i^0x017132 + 0x245726;
> }
> }
>
> TYPE res = 0;
> { // inner product
> for (int i = 0; i < SZ; i++) {
> res += v1[i] * v2[i];
> }
> }
>
> // printf("res=%i\ n", res.i);
> return (0);
> }[/color]

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.