5

If I use auto_ptr as a return value of a function that populates large vectors, this makes the function a source function (it will create an internal auto_ptr and pass over ownership when it returns a non const auto_ptr). However, I cannot use this function with STL algorithms because, in order to access the data, I need to derefference the auto_ptr. A good example I guess would be a field of vectors of size N, with each vector having 100 components. Wether the function returns each 100 component vector by value or by ref is not the same, if N is large.

Also, when I try this very basic code:

class t
{
    public: 
         t() { std::cout << "ctor" << std::endl; }
         ~t() { std::cout << "dtor" << std::endl; }
};

t valueFun()
{
   return t();
}

std::auto_ptr<t> autoFun()
{
   return std::auto_ptr(new t());
}

both autoFun and fun calls result with the output

Ctor Dtor

so I cannot actually see the automatic variable which is being created to be passed away to the return statement. Does this mean that the Return Value Optimization is set for the valueFun call? Does valueFun create two automatic objects at all in this case?

How do I then optimize a population of such a large data structure with a function?

tmaric
  • 5,347
  • 4
  • 42
  • 75
  • Are you asking whether RVO will also work for your large vectors? If so, can't you just test it with an example like the one above? – juanchopanza May 04 '12 at 13:40
  • When I test it, does it mean it works for all compilers/platforms? How do I know RVO is included at all, should I read the compiler specifications? What happens if the code is compiled on an HPC cluster with a different compiler, and the library is large? – tmaric May 04 '12 at 13:44
  • Yeah, I see your point. It is one of those things that the compiler is allowed, but not required to do, so you can never be sure. BTW do you have C++11 support? – juanchopanza May 04 '12 at 13:47

2 Answers2

4

There are many options for this, and dynamic allocation may not be the best.

Before we even delve in this discussion: is this a bottleneck ?

If you did not profile and ensured it was a bottleneck, then this discussion could be completely off... Remember than profiling debug builds is pretty much useless.

Now, in C++03 there are several options, from the most palatable to the least one:

  • trust the compiler: unnamed variables use RVO even in Debug builds in gcc, for example.
  • use an "out" parameter (pass by reference)
  • allocate on the heap and return a pointer (smart or not)
  • check the compiler output

Personally, I would trust my compiler on this unless a profiler proves I am wrong.

In C++11, move semantics help us getting more confident, because whenever there is a return statement, if RVO cannot kick in, then a move constructor (if available) can be used automatically; and move constructors on vector are dirt cheap.

So it becomes:

  • trust the compiler: either RVO or move semantics
  • allocate on the heap and return a unique_ptr

but really the second point should be used only for those few classes where move semantics do not help much: the cost of move semantics is usually proportional to the return of sizeof, for example a std::array<T,10> has a size equal to 10*sizeof(T) so it's not so good and might benefit from heap allocation + unique_ptr.

Tangent: you trust your compiler already. You trust it to warn you about errors, you trust it to warn you about dangerous/probably incorrect constructs, you trust it to correctly translate your code into machine assembly, you trust it to apply meaningful optimization to get a decent speed-up... Not trusting a compiler to apply RVO in obvious cases is like not trusting your heart surgeon with a $10 bill: it's the least of your worries. ;)

Matthieu M.
  • 287,565
  • 48
  • 449
  • 722
1

I am fairly sure that the compiler will do Return Value Optimization for valueFun. The main cases where return value optimization cannot be applied by the compiler are:

  • returning parameters
  • returning a different object based on a conditional

Thus the auto_ptr is not necessary, and would be even slower due to having to use the heap.

If you are still worried about the costs of moving around such a large vector, you might want to look in to using the move semantics(std::vector aCopy(std::move(otherVector)) of C++11. These are almost as fast as RVO and can be used anywhere(it is also guaranteed to be used for return values when RVO is not able to be used.)

I believe most modern compilers support move semantics(or rvalue references technically) at this point

  • The "fairly sure" is what bothers me a bit. :) From my standpoint, if I am to run this thing on 100s of cores and if it will grow with time, I need to be 100% sure of what the code does. – tmaric May 04 '12 at 13:53