RE: [Boost-users] Intoductory Boost Presentation

From: Darryl Green (Darryl.Green_at_[hidden])
Date: 2003-11-11 20:45:33

> -----Original Message-----
> From: Jon Kalb [mailto:Kalb_at_[hidden]] 
> Sent: Wednesday, 12 November 2003 7:22 AM
> To: Boost Users
> Subject: Re: [Boost-users] Intoductory Boost Presentation
> 
> 
> > the documentation (and the code?) deficient? That would be as useful
as
> > Matt's overview could be to those just getting into/considering
using
> > boost libs. As it stands, all that the above statement adds is FUD.
>
> I passed on my friend's comments without attribution because 
> I didn't ask
> his permission and I don't think he really intended the 
> comments for so
> large an audience. His comments were directed to our 
> co-workers and we know
> a little about some of the research that he has done on some 
> of the Boost
> libraries. With that audience it isn't exactly FUD.

I agree - FUD is audience dependent. I am 100% serious about thinking
that any addition that clarifies what the issues/pitfalls are would be
valuable, while FUD definitely isn't.

> 
> I will forward this message to him and ask if he wants to comment more
> specifically, but I'll give you one example that he found. I 
> don't recall
> the exact number, but he found that a function call using 
> Boost::function
> generated about 20K of code (in our development environment). 
> I realize that
> in a day when gigabyte hard drives are a dime a dozen it 
> seems miserly to
> worry about 20K, but that is for *one function call*. I don't think he
> benchmarked it to see how long it takes to execute this code, 
> but still I
> think he has a point when he talks about code bloat.

I'm sure he has a point. I only asked him to make it. I don't really
want this to turn into an attack on your co-worker's reasearch - I would
honestly like to see some information on these issues. We did some basic
tests on the performance of boost::function before using it and found
that the actual despatch overhead is very low (which was our main
concern at the time) and the size of the actual function wrapper is
acceptable. We have not (yet) used boost::function in a context where
the allocation performance would be expected to be significant. We
didn't specifically check code size, but I can safely say we don't see
20K/function call (and yes, we do care about code size - embedded
system). One thing that I have found with boost is that by providing
powerful concepts in its libraries it can replace a lot of bloatware
libraries/frameworks in a way that reduces overall code size, even
though toy benchmarks might indicate otherwise. 

> 
> I also think he has a point about discussing the performance 
> trade-off issue
> of each library. When the STL was first introduced, it was so 
> revolutionary
> that it was given a very skeptical reception. But most people 
> were won over.
> The power/overhead ratio was very favorable and it looked 
> like compilers
> would likely improve in ways that would make it even more favorable.

Absolutely agreed. Some of the stl tradeoffs don't fit some systems -
hence boost:array for example...

> 
> Now we are comfortable with template libraries and are less 
> skeptical of new
> ones. But every library has some overhead cost and has some 
> applications for
> which it is ill-suited. We need to evaluate each library on 
> its own merits
> and never assume that because one was accepted in Boost it 
> has some magic
> property that means there are no performance trade-offs or that the
> performance profiles of all Boost libraries are similar.

Yes - maybe something like that disclaimer would be a good start in an
introductory overview. It is ultimately up to the library user to
eveluate these issues - nothing special about boost in that regard.

> 
> Suppose users determine that Boost::function (I'm just 
> picking on this as an
> example) is great for creating flexible interfaces, but 
> should be avoided
> for any inner-loop use or where code size is at a premium. 

A user would have to determine that from an understanding of what a
boost::function really is/does and an understanding of their application
of it. In my opinion a statement similar to the above isn't a reasonable
way to present usage guidelines for boost::function. If you need a
generalised function interface in an inner-loop (hopefully rare) I can't
see that boost::function is going to be out-performed significantly by
anything else. If you are using a generalised function object interface
for invoking functions where the cost of an indirection in the call is a
significant part of the cost of the function (and the performance
actually matters) you have a design problem. As to code size - there
will always be places where code size matters, but I haven't seen a
problem - maybe a system where there are a huge number of different
boost::function specializations?

> That doesn't make
> the library worthless, in fact, adding advice about the best 
> situations to
> use the library enhances its value.

I agree - I really was asking you/your colleague to provide some
information to turn the FUD into something valuable. I don't think
boost::function needs any more guidelines, it is pretty well documented.
The only one I'd suggest emphasising in an introductory coverage is:

Carefully consider whether using boost::ref to avoid copying the target
function object is necessary/desirable for performance and/or semantic
reasons using boost::function.

I just checked, and this is covered in Douglas Gregor's tutorial anyway.

Maybe the guideline should just be RTFM.....

Regards
Darryl Green

##########################################################################
This e-mail is for the use of the intended recipient(s) only.  If you have 
received this e-mail in error, please notify the sender immediately and 
then delete it.  If you are not the intended recipient, you must not use, 
disclose or distribute this e-mail without the author's prior permission.  
We have taken precautions to minimise the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any 
attachment to this message.  We cannot accept liability for any loss or 
damage caused by software viruses.

##########################################################################