Re: [boost] [local] Help for the Alternatives section

Subject: Re: [boost] [local] Help for the Alternatives section
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-04-23 22:56:53

On Mon, Mar 28, 2011 at 12:21 PM, Thomas Heller
<thom.heller_at_[hidden]> wrote:
> Are you serious? Please write real benchmarks. By executing the resulting

Hello all,

I have profiled Boost.Local against all the alternative methods I know
for local functions:
    http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Alternatives.html#boost_local.Alternatives.local_functions.profiling

I was able to optimize Boost.Local code so it always runs as fast as
Local Functors. However, both Boost.Local and Local Functors run
significantly slower than Global Functors, Boost.Lambda, and
Boost.Phoenix on non C++03 compilers (see "Boost.Local Compliant"). On
C++03 compilers, Boost.Local runs faster than Local Functors and as
fast as Global Functors, Boost.Lambda, and Boost.Phoenix. All of that
when compiler optimization is used; When no compiler optimization is
used Boost.Local runs faster than both Boost.Lambda and Boost.Phoenix.
Boost.Local always compiles relatively fast and the same is true for
Boost.Lambda but not for Boost.Phoenix. I have also listed binary
sizes.

For the run-time, the point seems to be that the Boost.Local trick
that allows to pass local classes as template parameters requires 1
indirect function call via a function pointer:
    http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local/Implementation.html#boost_local.Implementation.local_classes_as_template_parameters
This indirect function pointer call can only be resolved at run-time
so compiler optimizations that inline all Boost.Lambda and
Boost.Phoenix functor calls cannot inline Boost.Local functor calls.
On C++03 compilers, Boost.Local passes the local class functor
directly as template parameter avoiding the function pointer indirect
call and therefore allowing for inlining all the Boost.Local functor
calls when compiler optimization is enabled.

I would think that the run-time cost of Boost.Local on non C++03
compilers (i.e., the use of 1 function pointer in resolving the local
function call) might still be acceptable in applications that already
use a number of indirect function calls (via function pointers,
virtual functions, etc). Furthermore, I have not experimented how the
run-time performances of Boost.Local and the other approaches are
affected by programming more complex instructions in the local
function body (the local function used in this analysis simply adds
the elements of an array and it contains only one instruction `sum +=
factor * num`).

What do you think? Thanks.

-- 
Lorenzo