Behaviour of templated class wrapping a member function call - c++

Question

I have a function of a class I would like to iteratively call inside a loop, and while the loop is fixed, I want to be able to provide different functions (from the given object). To approach this, I created a templated struct MyWrapper to take the object whose function I want to call, the function itself, and data for which to evaluate the function. (In that sense, the member function will always have the same signature)
What I found though, was that using a member function pointer incurs a huge performance cost, even though at compile time, I know the function I want to call. So I was messing around to try and fix this, and (while I'm still unclear why the first situation happens), I've experienced another interesting behaviour.
In the following situation, every call to the wrapper function MyWrapper::eval will actually attempt to copy my whole Grid object into the parameter to the given function it has to wrap, f, even though the call to MyEquation::eval will know not to copy it every time (because of optimization).
template<typename T>
double neighbour_average(T *v, int n)
{
return v[-n] + v[n] - 2 * v[0];
}
template<typename T>
struct MyEquation
{
T constant;
int n;
T eval(Grid<T, 2> v, int i)
{
return rand() / RAND_MAX + neighbour_average(v.values + i, n) + constant;
}
};
template<typename T, typename R, typename A>
struct MyWrapper
{
MyWrapper(T &t, R(T::*f)(A, int), A a) : t{ t }, f{ f }, a{ a } {}
auto eval(int i)
{
return (t.*f)(a, i);
}
protected:
A a;
T &t;
R(T::*f)(A, int);
};
int main(int argc, char *argv[])
{
srand((unsigned int)time(NULL));
for (iter_type i = 0; i < config().len_; ++i)
{
op.values[i] = rand() / RAND_MAX;
}
srand((unsigned int)time(NULL));
double constant = rand() / RAND_MAX;
int n = 2;
int test_len = 100'000,
int test_run = 100'000'000;
Grid<double, 2> arr(100, 1000);
MyEquation<double> eq{ constant, n };
MyWrapper weq(eq, &MyEquation<double>::eval, arr); // I'm wrapping what I want to do
{
// Time t0("wrapper thing");
for (int i = 0; i < test_run; ++i)
{
arr.values[n + i % (test_len - n)] += weq.eval(n + i % (test_len - n)); // a call to the wrapping class to evaluate
}
}
{
// Time t0("regular thing");
for (int i = 0; i < test_run; ++i)
{
arr.values[n + i % (test_len - n)] += rand() / RAND_MAX + neighbour_average(arr.values + n + i % (test_len - n), n) + constant; // a usage of the neighbour function without the wrapping call
}
}
{
// Time t0("function thing");
for (int i = 0; i < test_run; ++i)
{
arr.values[n + i % (test_len - n)] += eq.eval(arr, n + i % (test_len - n)); // raw evaluation of my equation
}
}
}
Some context:
Grid is just a glorified dynamic array Grid::values with a few helper functions.
I've retained some of the (seemingly unnecessary) templates to my function and object, because it closely parallels how my code is actually set up.
The Time class will give me the duration of the object lifetime, so its a quick and dirty way of measuring certain blocks of code.
So anyways...
If the following code is changed so the signature of the function taken by MyWrapper is R(T::*f)(A&, int), then the execution time of MyWrapper::eval will be almost identical to the other calls (which is what I want anyways).
Why doesn't the compiler (msvc 2017) know it should treat the call weq.eval(n) (and consequently (t.*f)(a, n)) the with the same optimization considerations way as the direct evaluation, if the signature and function is given at compile time?

Answer 1

A function parameter is its own variable, which gets initialized from a function call argument. So when a function argument in the calling function is an lvalue such as the name of an object previously defined, and the function parameter is an object type, not a reference type, the parameter and the argument are two different objects. If the parameter has a class type, this means a constructor for that type has to be executed (unless the initialization is an aggregate initialization from a {} initializer list).
In other words, every call to
T eval(Grid<T, 2> v, int i);
needs to create a new Grid<T, 2> object called v, whether it's called via function pointer or by the member name eval.
But in many cases, initialization of a reference doesn't create a new object. It appears your eval doesn't need to modify v or the MyEquation, so it would be better to declare that eval as:
T eval(const Grid<T, 2> &v, int i) const;
This would mean the function pointer in Wrapper needs to be R (T::*f)(const A&, int) const.
But another change you might want to make, especially since Wrapper is already a template: Just make the function used a generic type, so that it can hold non-member function pointers, wrappers to member function pointers with any signature, lambdas, or any other class type with an operator() member.
#include <utility>
template<typename F, typename A>
struct MyWrapper
{
MyWrapper(F f, A a) : f{ std::move(f) }, a{ std::move(a) } {}
auto eval(int i)
{
return f(a, i);
}
protected:
A a;
F f;
};
Then two ways to create your Wrapper weq; are:
Wrapper weq([&eq](const auto &arr, int i) {
return eq.eval(arr, i);
}, arr);
or (requires #include <functional>):
using namespace std::placeholders;
Wrapper weq(
std::bind(std::mem_fn(&MyEquation<double>::eval), _1, _2),
arr);