Thread: Lambda captures are inefficient?

Compiler: VS2010

I'm having an interesting performance problem. I have a class which provides a ForEach method that takes a lambda as its parameter. I'm trying to use the lambda to count the number of iterations. Boiled down, the case looks like this:

Code:

class Foo
{
public:
    template <typename F>
    void ForEach(F func)
    {
        // ... calls func() a number of times
    }
};

// Invocation site:
Foo foo;
int counter = 0;
foo.ForEach([&]()
{
    ++counter;
});

This works correctly, of course, but the compiler generates less-than-optimal assembly code. The anonymous class the compiler creates to implement the lambda contains a pointer to the counter variable. On each iteration of ForEach(), the generated code obtains this pointer from memory and then dereferences it to increment the counter. This is doubly non-optimal, as the compiler could have simply kept count in a register and written to memory at the end of the loop, but instead it performs TWO memory accesses (one to get the pointer from the lambda, then another to get the variable itself by dereferencing the pointer) for each iteration.

I suspected that declaring the counter variable as static would improve matters. Indeed it does, with the generated code simply keeping count inside a register as expected. The resulting code is 25% faster!

It is almost as if the compiler is treating, not only the counter variable but the pointer to it, as volatile! This seems extremely pessimistic. I'm bummed, because making it static is a hack and I don't want to do it.

Does anybody have a clue why the compiler is being so pessimistic? Something in the C++11 standard maybe?

EDIT: I forgot to mention that the compiler is inlining everything together -- it generates a specialized ForEach() which does the loop and increments the variable in line, with no function call to dispatch to the lambda. So the compiler should in theory be perfectly capable of realizing that the pointer never changes and thus it COULD cache the counter in a register... It just doesn't.

Does the same happen for the following code ?

Code:

#include<functional>
#include<iostream>
#include<vector>
class Foo
{
public:
    Foo():foo({1,2,3,4,5}){}
    template <typename F>
    void ForEach(F func)
    {
        for(auto x:foo)func();
    }
    std::vector<int> foo;
    
};
int main()
{
    Foo foo;
    int counter = 0;
    foo.ForEach
    (
        std::bind
        (
            [](int& i){++i;}
            ,std::ref(counter)
        )
    );
    std::cout<<counter;
}

If so, it *may* just be the quirk of the compiler.(You'll probably see the same in all 'call by reference' cases.)

If not, it could be due to how lambdas must treat objects captured by reference...(I have no idea.)

You didn't say whether you were building a Release or Debug build or what optimization level you set.

Try a release build with maximum optimization.

Originally Posted by manasij7479

Does the same happen for the following code ?

VS2010 can't compile that

I'll see if I can do something similar, though.

I'm using standard Release build settings, which is not the highest optimization. Turning optimization up makes no difference, it looks like.

Originally Posted by phantomotap

O_o

Would you do me the favor (I don't have 2010.) of profiling explicitly using a pointer and an address?

I know it is less than convenient, but could you also profile explicitly "wrangling" a pointer to a reference within the lambda.

You mean like this?

Code:

class Foo
{
public:
    template <typename F>
    void ForEach(F func)
    {
        // ... calls func() a number of times
    }
};
 
// Invocation site:
Foo foo;
int counter = 0;
int *pCounter = &counter;
foo.ForEach([&]()
{
    ++*pCounter;
});

If so, I already tried that and found that the compiler generates identical code to the first case.