On Sun, Apr 24, 2011 at 6:09 AM, John Bytheway <jbytheway+boost@gmail.com> wrote:
On 24/04/11 03:56, Lorenzo Caminiti wrote:
On Mon, Mar 28, 2011 at 12:21 PM, Thomas Heller <thom.heller@googlemail.com> 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: http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_local...
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 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2657.htm .
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... 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. -- Lorenzo