[function] new implementation

30 Oct 2010

      Hi,

<...those that followed the latest function related discussions can skip the 
first paragraph...>

For about a year and half now (or even more but that's about how long I've 
been involved in the matter) there have been repeated 
discussions/requests/complaints about various aspects of Boost.Function. 
Most of those fall into one or more of these categories:
 - overall code speed overhead
 - overall code bloat overhead
 - lack of configurability
 - dependencies on RTTI and exception handling
with the most frequently brought up specific issue being the various 
implications (in all of the above mentioned areas) of the hardcoded 
throw-on-empty behaviour...

Unfortunately Boost.Function code remained virtually unchanged (except for 
the added RTTI emulation for platforms w/o RTTI support) with all of the 
issues still remaining...

The new implementation proposal @:
https://svn.boost.org/svn/boost/sandbox/function/boost/function
http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Function 
Objects
solves or at least provides drastic improvements for all of the mentioned 
issues.

It is intended as a drop in replacement for the current implementation and 
as such I have so far tested it in the following ways:
 - compiling some real world code: VC10, GCC 4.2.1, LLVM-GCC 4.2.1, GCC 
4.5.1, GCC 4.6, Clang 2.0, Clang 2.8
 - compiling and running a real world project: VC10, Clang 2.8
 - building Boost trunk: VC10, GCC 4.2.1, GCC 4.5.1, Clang 2.0
 - running Boost regression tests for Function, Signals, Signals2, Thread, 
Program Options and Graph libraries: VC10, GCC 4.2.1, Clang 2.0.
(All of the tests passed except for two bogus assertion failure boxes that 
pop up with VC10 and the Program Options tests during the automated 
regression test procedure that OTOH do not popup when I run the same tests 
manually through the VC10 IDE, i.e. the tests finish successfully...I tried 
to make sure all the relevant compiler switches were the same in both cases 
so I am out of ideas what else can make the difference.....)

Next, let me give you a comparison of for-size-optimized code generated by 
VC10 with both the current and the proposed implementation for a short code 
snippet demonstrating invocation, construction and assignment:

struct X
{
    int foo( int const x ) const { return x + y; };
    int y;
};

int main( int /*argc*/, char * * /*argv*/ )
{
    using namespace boost;

    X x;
    function<int(int)> foof( boost::bind( &X::foo, &x, _1 ) );

    foof( 0 );

    function<int(int)> barf;

    barf = foof;
    barf( 1 );

    return 0;
}

Notice in new_function_code_listing.txt how all of the wrapper code in the 
new Function was completely transparent to the compiler and was completely 
inlined to relatively simple machine code with direct calls to/through the 
vtable pointers...while OTOH in current_function_code_listing.txt the code 
generated for the "barf = foof;" assignement alone is several times larger 
than the entire code generated for the new Function implementation.

The small asm snippet of the generated invoker/'thunk'/'trampoline' code 
also demonstrates the effects of various tweaks done to minimize or all 
together remove the need for any stack adjustment on the invoker side...

The new implementation of course has the same semantics and exception safety 
guarantee levels as the original/current one.

Listing all of the improvements and detailed implementation changes here in 
the first post would be quite cluttering as they are quite numerous. Those 
that desire more tests and details right now, can follow this trail:
http://lists.boost.org/Archives/boost/2010/01/160908.php

As for the dependencies issue this is solved in several ways:
 - use of exception handling: new code uses guard objects instead of 
explicit exception handling and provides a way to change on-empty-behaviour 
so that the EH code/dependency can easily be removed/disabled
 - use of RTTI (for getting the type of the stored function object): this 
can be globally disabled with the BOOST_FUNCTION_NO_RTTI macro. 
BOOST_NO_RTTI is not used for this purpose for backward compatibility 
reasons: in the current implementation it actually turns on RTTI 
emulation...The idea is to also add per instantiation RTTI on-off 
configurability...

'Configurability' will probably be the most controversial issue/change 
because it required the addition of an extra template parameter through 
which an MPL list of policies can be specified at compile-time. This 
parameter is properly defaulted to allow existing code to compile without 
changes while providing current Boost.Function behaviour (e.g. on-empty- 
behaviour). As all the performed tests showed this to also be true in 
practice the proposed code should IMO go in as a straight drop-in 
replacement but, of course, I might have missed some important higher level 
detail/concern so this is open to discussion...
Currently two policies are supported:
 - on throw behaviour (with throw-on-empty, nop-on-empty and assert-on-empty 
handlers provided)
 - whether the function instantiation should mark itself (i.e. its 
operator()) as nothrow.
Additional policies my be added later, for example:
 - sizeof and/or alignment of the SBO buffer
 - default allocator
 - per instantiation RTTI on/off
...

Finally, there is one more addition, somewhat 'unholy' as it brings in the 
concept of binding into Boost.Function but considering its efficiency and/or 
verbosity benefits (and the fact that the first issue can be 'explained 
away' by saying that this is not actually 'binding' but a workaround for the 
lack-of-delegates-support C++ language deficiency).
The addition is in the form of two more assign() member function overloads 
(one for a free function that has the exact signature as the Boost.Function 
instantiation, and one for a member function that has a matching signature 
with the addition of a this pointer) that allow assignment of (suitably 
typed) plain (free or member) functions specified as non-type-template 
parameters. This allows for the removal of the extra 
indirect-call-through-function-pointer otherwise incurred by traditional 
assignment of function pointers (not functors), which is actually a rather 
common use case. For example, in the above example given, one can now write:

  foof.assign<X, &X::foo>( x );

and get a trivial invoker with the X::foo() target function inlined straight 
in...

-- 
"What Huxley teaches is that in the age of advanced technology, spiritual
devastation is more likely to come from an enemy with a smiling face than
from one whose countenance exudes suspicion and hate."
Neil Postman

Domagoj Saric

Domagoj Saric

Lars Viklund

Domagoj Saric

Domagoj Saric

Lars Viklund

Domagoj Saric

Lars Viklund

Domagoj Saric

Sebastian Redl

Domagoj Saric

Sebastian Redl

Lars Viklund

Domagoj Saric

Lars Viklund

Domagoj Saric

Hartmut Kaiser

Domagoj Saric

Hartmut Kaiser

Hartmut Kaiser

Domagoj Saric

David Abrahams

Domagoj Saric

Hartmut Kaiser

Domagoj Saric

Domagoj Saric

Frank Mori Hess

Domagoj Saric

tags

participants (7)