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

Subject: Re: [boost] [local] Help for the Alternatives section
From: John Bytheway (jbytheway+boost_at_[hidden])
Date: 2011-04-24 06:09:43

On 24/04/11 03:56, Lorenzo Caminiti wrote:
> 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 feel that including the "for loop" implementations is cluttering the
graphs to no useful purpose.  The only place it's obviously different
from the other is in the unoptimized runtime.  Also, I'd suggest putting
the pictures in a different order: runtime first, then compile time,
then binary size; I guess that's closer to what a typical developer
cares about.  It might also help to put the legend at the top; I didn't
notice it for a while and I was confused by how the entries in the
graphs corresponded to the source files linked to.

> 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.

When you say "non C++03" and "C++03", do you in fact mean "non C++0x"
and "C++0x"?  (Indeed, you may wish to dare to call it "C++11" at this
point).  These results and comments don't make much sense otherwise.

> 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.

This is not really true. The call *could* be resolved at compile-time in
theory, it's just that no compiler has been observed to do it.

John