2

This time, I couldn't find what I'm looking for (dunno if I'm not searching for the right stuff...) but, here it is:

In c++, imagine you have a function Bar() that is called once every cycle... like this:

class Foo {
 public:
   void Bar() {
     double my_array[3]; 
     // fills the array based on some calculations
     double my_array1[3]; 
     // fills the array based on some calculations
     double my_array2[3];
     // fills the array based on some calculations
     _member_of_class = my_array + my_array1 + my_array2; //+ overloaded
   }

 private:
   float _member_of_class[3];
}

int main(int argc, char** argv) {
  Foo foo;
  while(/*program running*/) {
    foo.Bar();
    //LOTS of code here
  }
  return 0;
}

Now, my_arrays are temporary arrays, not important to be data members, just used to fill the class member... Obviously, the overhead of calling that function is not necessary... Is there a way (well, I'm trying to avoid putting them as class members) of telling the compiler to "save the allocation space" or something so they is less overhead? const would give any tip to the compiler? I'm not sure I'm being clear...

Anyway, thanks!

jonsca
  • 10,218
  • 26
  • 54
  • 62
André Patrício
  • 23
  • 2

4 Answers4

3

Use a profiler

As it stands, the function is declared inline in a class. This code will trivially optimize, and the compiler will probably get the allocations out of the loop anyway (depending on how much cruft you have left out of the picture, really).

Also, the overloaded array operators likely get vectorized in gcc (starting with -O3 of -ftree-vectorize). Just look at the verbose out put with

g++ -O3 -march-native -ftreevectorizer-verbose=2 ...

to see what loops got vectorized, and if not, why not. By all means have a look at the output of g++ -S etc.

Use a profiler. Don't 'optimize' if you don't know that it's necessary.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • Sadly I started the whole project in vs2010, so g++ is out of my range... Do you know any way of doing that with vs? BTW, the tip about profiling is great... But it's really a question I'd like to get answered too... – André Patrício May 07 '11 at 23:39
  • I [understand that MSVC++ has 'decent' optimizations](http://www.agner.org/optimize/#manuals) (not as fancy as gcc or as targeted as Intel); Most non-frugal versions of Visual Studio come with performance analyzer tools (that I don't really know how to operate anymore, last used in VS 6...). [You might just search SO for 'VC++ profiler' instead asking it; I'm sure it came up before](http://stackoverflow.com/questions/292457/profiler-for-visual-studio-2008-c) – sehe May 07 '11 at 23:44
  • +1 for the first link... Also, I guess it is the most complete answer (with that last comment) – André Patrício May 08 '11 at 01:09
  • +1 for "Use a profiler. Don't 'optimize' if you don't know that it's necessary. " – Rich May 09 '11 at 14:04
0

You can declare the arrays as static. This will force the compiler to reserve some memory for them, rather than putting them on the stack each time you call the function. Keep in mind that this breaks thread-safety, however.

Also remember that the stack is pre-allocated; this code isn't actually allocating any new memory for your arrays, it's only placing them in memory that's already allocated. There is no overhead here. Your compiler can reserve space for all three arrays with only one instruction.

Collin Dauphinee
  • 13,664
  • 1
  • 40
  • 71
  • But, in my case, it's a Vector implementation... Vector is a class... Would it create a new instance per cycle? So, without compiler self-optimizations: 'for (int i = 1000; i > 0; --i) { static Myclass a; a.foo(); }' would be the same as: 'for (int a = 1000; a > 0; --a) { _previously_instantiated_class.foo(); }' ? – André Patrício May 07 '11 at 23:32
0

Pass them as parameters to the Bar function. Arrays decay into pointers and will be quite fast to pass.

Pepe
  • 6,360
  • 5
  • 27
  • 29
0

Why not consider making the arrays private members? If you want to guarantee no overhead in stack allocation during runtime making them private members would make it clear to other programmers that that is what was happening , where as compiler switches or relying on optimisations automatically done by the compiler aren't always obvious to other devs.

Rich
  • 4,572
  • 3
  • 25
  • 31
  • 1
    It wouldn't make sense (abstraction)... Imagine you want to compute the lateral component of velocity in some car... || Vector perpendicular_to_car = cross(direction, z_axis); _lat_vel = dotproduct(velocity, perpendicular); || why would I want to store perpendicular as a data member? the problem is solvable like you said, but it's not that elegant, is it? IMHO I think that should be something possible to do... I think static does that job, like @dauphic said, but breaks thread-safety... – André Patrício May 08 '11 at 00:36
  • IMHO static is as bad as private if you're considering it from an abstraction point of view. If you take a purist attitude to form over function then you end up losing function as a result. Try justifying caching from the point of view of abstraction, it also makes no sense but we do it for the sake of optimisation where necessary. – Rich May 09 '11 at 00:13