[function] Merits of drop-in replacement
I ran across http://www.codeproject.com/cpp/fastdelegate2.asp the other day. I searched the archives and didn't find any discussion about it on the list. It makes some good arguments and seems to be done pretty well, although it may have succumb to a bit of feature creep. Should those benchmarks be reran against the trunk version of Boost.Function? Thanks, Michael Marcin
On Sep 14, 2007, at 4:05 PM, Michael Marcin wrote:
I ran across http://www.codeproject.com/cpp/fastdelegate2.asp the other day. I searched the archives and didn't find any discussion about it on the list.
It makes some good arguments and seems to be done pretty well, although it may have succumb to a bit of feature creep.
Should those benchmarks be reran against the trunk version of Boost.Function?
Yes, those tests should certainly be rerun now that Boost.Function does the small-object optimization. Copy performance for such small objects is much, much improved. - Doug
Doug Gregor wrote:
On Sep 14, 2007, at 4:05 PM, Michael Marcin wrote:
I ran across http://www.codeproject.com/cpp/fastdelegate2.asp the other day. I searched the archives and didn't find any discussion about it on the list.
It makes some good arguments and seems to be done pretty well, although it may have succumb to a bit of feature creep.
Should those benchmarks be reran against the trunk version of Boost.Function?
Yes, those tests should certainly be rerun now that Boost.Function does the small-object optimization. Copy performance for such small objects is much, much improved.
I once hacked a quick benchmark to compare dispatch times of Bind&Function (1.34 versions) vs. FastDelegate. With an inlineable replacement for 'boost::mem_fn' (accepting the member function pointer as a non-type template argument) http://tinyurl.com/37tkap FastDelegate turned out to be (not quite) twice as fast as Function&Bind with MSVC, which isn't that much IMO held against the lost flexibility, such as not being able to use arbitrary function objects and only binding 'this'. However, things looked quite a bit worse with GCC (version 4 IIRC, don't remember the exact numbers), a good chunk of it because of not-optimized compile-time const member pointers. So FastDelegate is still be several times faster when it comes to member function pointers that are runtime values... Regards, Tobias
On Mon, 2007-09-17 at 21:23 +0200, Tobias Schwinger wrote:
I once hacked a quick benchmark to compare dispatch times of Bind&Function (1.34 versions) vs. FastDelegate.
With an inlineable replacement for 'boost::mem_fn' (accepting the member function pointer as a non-type template argument)
FastDelegate turned out to be (not quite) twice as fast as Function&Bind with MSVC, which isn't that much IMO held against the lost flexibility, such as not being able to use arbitrary function objects and only binding 'this'.
FastDelegate will always have faster invocation, because it optimizes for a very narrow set of cases. The invocation performance of Boost.Function won't have changed much from 1.33.x to 1.34.x. It's the copy performance that drastically improved. That part of the benchmark should be re-run with Boost 1.34.x. - Doug
Hi Doug, Douglas Gregor wrote:
On Mon, 2007-09-17 at 21:23 +0200, Tobias Schwinger wrote:
I once hacked a quick benchmark to compare dispatch times of Bind&Function (1.34 versions) vs. FastDelegate.
With an inlineable replacement for 'boost::mem_fn' (accepting the member function pointer as a non-type template argument)
FastDelegate turned out to be (not quite) twice as fast as Function&Bind with MSVC, which isn't that much IMO held against the lost flexibility, such as not being able to use arbitrary function objects and only binding 'this'.
Well, I have to correct myself. It's been a while since I last looked at it and it seems to have improved (as it does handle function objects, by now).
FastDelegate will always have faster invocation, because it optimizes for a very narrow set of cases.
True. It seems the narrow set has become a bit wider, though. However, Boost.Function in itself is not looking that bad, performance-wise. Please note, however, that the great performance is achieved by restricting ourselves to member function pointers known at compile time (and a compiler that can exploit this information). It's the invocation routine for member pointers emitted by the compiler that makes up most of the difference. It might be possible to modify Bind to implement the variants for the "FastDelegate mess" and some introspection for Function to "invokerize" the correct variant [for the protocol: this sentence assumes familiarity with implementation details of Boost.Function].
The invocation performance of Boost.Function won't have changed much from 1.33.x to 1.34.x. It's the copy performance that drastically improved. That part of the benchmark should be re-run with Boost 1.34.x.
FWIW, I'm fine just believing that calling operator new is slower than not calling it ;-). Regards, Tobias
Tobias Schwinger wrote:
Doug Gregor wrote:
On Sep 14, 2007, at 4:05 PM, Michael Marcin wrote:
I ran across http://www.codeproject.com/cpp/fastdelegate2.asp the other day. I searched the archives and didn't find any discussion about it on the list.
It makes some good arguments and seems to be done pretty well, although it may have succumb to a bit of feature creep.
Should those benchmarks be reran against the trunk version of Boost.Function? Yes, those tests should certainly be rerun now that Boost.Function does the small-object optimization. Copy performance for such small objects is much, much improved.
I once hacked a quick benchmark to compare dispatch times of Bind&Function (1.34 versions) vs. FastDelegate.
With an inlineable replacement for 'boost::mem_fn' (accepting the member function pointer as a non-type template argument)
FastDelegate turned out to be (not quite) twice as fast as Function&Bind with MSVC, which isn't that much IMO held against the lost flexibility, such as not being able to use arbitrary function objects and only binding 'this'.
However, things looked quite a bit worse with GCC (version 4 IIRC, don't remember the exact numbers), a good chunk of it because of not-optimized compile-time const member pointers.
So FastDelegate is still be several times faster when it comes to member function pointers that are runtime values...
There are several fast delegates floating around. I saw discussion in the archives about: http://www.codeproject.com/cpp/fastdelegate.asp but not http://www.codeproject.com/cpp/fastdelegate2.asp which is completely different AFAIK. Which did you compare against before? Thanks, Michael Marcin
participants (4)
-
Doug Gregor -
Douglas Gregor -
Michael Marcin -
Tobias Schwinger