How does modern compiler optimize function object in c++? - c++

Question

As I knew from the book Effective C++, it would have a better performance if I pass a Function Object by its value rather than function reference or function pointer in C++. So how does the modern compiler do to optimize that kind of scenario?
Or let's say usually we do not recommend to pass an object of our self-customized class by value, but as function object is actually the same as a normal object but just implemented the "operator()" inside the class. So, there must be something different for the compiler to treat these two things when passing them by value, right?
Below is a case giving a comparison between the function object and function pointer.
#include <algorithm>
#include <vector>
#include <ctime>
#include <iostream>
bool cmp(int a, int b) { return a < b; }
int main() {
std::vector<int> v(10000000);
for (size_t i = 0; i < 10000000; ++i)
v.push_back(rand());
std::vector<int> v2(v);
std::sort(v.begin(), v.end(), std::less<int>()); // This way would be faster than below;
std::sort(v2.begin(), v2.end(), cmp);
}

Answer 1

In case of function pointer, compilers is likely to pass function pointer and performing indirect function call, instead of making direct function call or even inlining.
In contrast, operator() of a function object is likely to inline, or at least be called directly, since it is not passed, only data to it is passed (by value or by reference). In case of function object without data, you pass nothing (that would compile to a dummy integer, or even nothing).
Especially it is true with std::function, there's almost no way from implementation side to avoid double indirect function call in case of function pointer.
A lambda is easiest way to make this optimization. Here is your example with one character difference:
#include <algorithm>
#include <vector>
#include <ctime>
#include <iostream>
int main() {
std::vector<int> v(10000000);
for (size_t i = 0; i < 10000000; ++i)
v.push_back(rand());
std::vector<int> v2(v);
std::sort(v.begin(), v.end(), [] (int a, int b) { return a < b; }); // This way would be faster than below;
std::sort(v2.begin(), v2.end(), +[] (int a, int b) { return a < b; });
}
Modern compilers did not go much further than old compilers in this regard. Although you can try your example on different modern compilers to check for sure (you can use https://godbolt.org/ and inspect disassembly)

Answer 2

In case of gcc 7.5, std::sort uses internally __gnu_cxx::__ops::_Iter_comp_iter template which looks like that:
template<typename _Compare>
struct _Iter_comp_iter
{
_Compare _M_comp;
explicit _GLIBCXX14_CONSTEXPR
_Iter_comp_iter(_Compare __comp) : _M_comp(_GLIBCXX_MOVE(__comp)) { }
template<typename _Iterator1, typename _Iterator2>
_GLIBCXX14_CONSTEXPR bool
operator()(_Iterator1 __it1, _Iterator2 __it2)
{ return bool(_M_comp(*__it1, *__it2)); }
}
In the first case _Compare is std::less<int>, in the second -- bool (*)(int, int).
In the first case gcc inlines comparison, while in the second it generates something like callq *%r13 to call that pointer stored in _M_comp.
Update:
After more digging around prompted by comments, it turns out that the problem is not in the type of _Compare -- gcc 7.5 can inline small pure functions with function pointers, too, even without inline modifier -- but rather in presence of recursion in the internal workings of std::sort. That throws the compiler off and it generates indirect call. Good news is that gcc 8+ seems to be free of this drawback.