Subject: Re: [boost] [local] Help for the Alternatives section
From: Lorenzo Caminiti (lorcaminiti_at_[hidden])
Date: 2011-05-01 18:18:07
On Sun, Apr 24, 2011 at 6:09 AM, John Bytheway
> 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:
I have made some changes to profiling for MSVC 8.0 on Windows XP plus
I have added profiling for GCC 4.5.1 with C++0x (including lambdas) on
Linux and GCC 4.3.4 (plain ISO C++) on Cygwin:
> 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 have remove the Boost.Local for-loop implementation but I have left
the for-loop implementations only for Local Function Inline (before
called NAME_OPTIMIZED) and for Local Functor because they cannot be
passed as template parameters on ISO C++.
>> 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.
Yes, I have changed that. Specifically I am referring to C++0x N2657
>> 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:
>> 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.
Yes, I have tried to state this correctly in Boost.Local docs.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk