[Xorp-hackers] Boost use

[Ben Greear]

On 04/24/2010 08:30 PM, Bruce Simpson wrote:
> On 04/23/10 18:10, Mark Handley wrote:
>> Regarding boost, I think how we left it on the phone call last night
>> was that Bruce would write a short note saying what he believes boost
>> gives us, and why it's the right thing for Xorp.  So I'd like to wait
>> for that before we make a decision.
>>
>
> I have set out many of the benefits Boost offers for XORP, in previous
> postings to this mailing list over the last 6-9 months, so I'll be as
> concise here as possible:
>
>       * Boost is widely used by C++ projects of comparable size, and
> offer a thoroughly peer-reviewed alternative to some of what we have in
> libxorp.
>       Innovations from Boost itself are becoming part of the C++0x
> language specification. It is technically very strong.
>       I think it's unreasonable to expect folk to reinvent wheels which
> exist out there, and pretty much essential to stuff they're now doing;
> Boost can be considered part of the C++ state-of-the-art now, as such,
> it has project currency.
>
>       * The Boost shared_ptr/weak_ptr idioms, are a clean solution,
>         to very specific problems we see in async systems such as XORP.
>
>       That is, where we need to cleanly separate the reference of a C++
> object from its storage lifecycle.
>       Abusing ref_ptr further is syntactically not clear at all, and I
> strongly feel we should be using Boost instead. I am opposed to further
> use of ref_ptr (with&) because the intent of it is overloaded and
> confusing, to developers who are not intimately familiar with ref_ptr.
>       Far more C++ developers out there are likely to be familiar with
> Boost than libxorp.

The ref-pointer logic might could be done better, but I don't think we need
to include boost to do that.  We could, for instance, use a 'RefCountable'
base class that stores a ref count, and a RefPointer objec that stores a pointer
to RefCountable and manages the object lifetime.  In general, I think we
should minimize ref-pointer usage where possible, but in some places,
it is quite useful.

With regard to passing by reference or value, I do not understand the
confusion.  It's no different than any other object in that regard
and anyone programming in C++ just needs to understand the difference
in passing by ref v/s passing by value.

>       * The Boost.Interprocess library will enable using shared memory
> efficiently for fast-path IPC in future, something which currently slows
> down XORP *significantly* compared to other BGP designs;
>       14m vs 1m for full routing table convergence.
>       As I've said to Mark and others before, there are shared-memory
> versions of the list, map and other STL containers, which drop straight
> in to shared memory.
>       [FWIW Ravi at XORP, Inc. was proposing doing much the same thing,
> but hand-rolled]

Shared memory would require locking and/or message passing, and allows one
app to corrupt another.

My perf tests show in excess of 100,000 XRL transactions per second.  I suspect
that the main performance problem is that much of xorp is implemented to
allow only a single outstanding XRL at any given time.  We would likely
gain a great deal of performance by just implementing batching for operations
needing lots of XRLs.

I'd love to be able to reproduce this 14m v/s 1m BGP issue, but to date,
I haven't found a way to do that.  If anyone can help set up such a test,
I am very interested in diagnosing it.

>       * The Boost multi-index container has the potential to make large
> indexed structures, such as the RIB tables, and routing tables internal
> to most protocols, more efficient in time and space.
>       [I would have used it for OLSR, but ran out of time]

This sounds interesting, and might be a reason to look at boost again in
the future if/when someone had interest in implementing this sort of thing,
but without a patch to actually use this feature and some demonstration
of actual gain, it is not enough reason to start using boost in my opinion.

>       * Thrift requires Boost anyway. Despite forwarding the full
> reasoning behind my recommendation of Thrift to XORP, Inc., to replace
> much of XRL and fix the problems with it, I have still not had an
> opinion from Mark either way.

Again, XRL may not be perfect, but it seems relatively fast as is,
and there are several easy memory new/delete optimizations waiting
for an hour or two of time to implement.  If, as I suspect, the
root cause of performance issues is non-batching use of the IPC
mechanism, we just need to change the higher level code, and even
if XRL layer was infinitely fast, it would not solve the problem
without fixing the higher-level code.

>       * There are numerous other Boost refactorings possible. I did not
> finish them because life support went offline.
>
>       * Finally: We have already had others on xorp-hackers@ come
> forward, to say that work they've been doing on XORP requires Boost. Off
> the top of my head, Luca Belforte, for marshaling compound data
> structures out of routing processes.

No one has offered lately.  If someone plans to actively work on the public
XORP SVN tree and wants to use boost, hopefully they can also speak up
in support of using Boost.

> I don't buy the argument that '1 more external dependency is bad'. The
> Boost libraries as currently used, are mostly used as header files.
> However beyond regex, we don't use the runtime libraries. The use of the
> libraries, can easily be switched back over to pcre or platform regex
> (at a minimum). At the moment boost regex is just shimmed in.

The default regex works fine (at least on Linux), and I didn't even
have to link against any external libraries.  From what I can tell,
this is also the case on BSD.

> My view is that this argument is rooted more in unfamiliarity with
> systems-level C++, and how to optimize it effectively, than it actually
> posing a real problem.
>
> Boost is generally available as a binary package for the platforms
> tested by the Tinderbox.
> The Boost headers don't have any cross-compilation implications, apart
> from what someone cross-compiling XORP would need to do for an embedded
> target anyway, i.e. populate the staging area.

The downsides of boost for me are:

1)  It's a large, complex set of libraries that one would have to understand well to
   make good use of or even read boost-enabled xorp code.  It doesn't seem like
   it would replace any sizeable amount of Xorp logic, so it's simply more learning
   curve to overcome for anyone who doesn't already know boost.

2)  It is not installed by default on Fedora Linux (and others).  This means that users
   must install this to use xorp.  In some ways, this is a minor problem easily fixed, but
   it is one more impediment that might discourage new users.  Also, that it is not required
   by the base install of Fedora, indicates to me that it is not that widely used, at least in
   Linux.

2b.  It is a pain to get xorp-svn to compile on Ubuntu because you have to install a specific
   version of boost, and ubuntu has 2 to choose from.

3)  For anyone working with constrained amounts of disk storage, lib-boost is a large
   amount of extra disk space.

> I'd far rather see a release made than not, if only to regain confidence
> with an otherwise unheard-from user base.
> If the use of libboost_regex is the issue, that's a point I'm willing to
> compromise on for 1.7.
>
> But I'm not willing to do the work of backing anything out, as I firmly
> believe it's in XORP's future interests for the reasons given above.
> This is view borne in experience of being the only active developer on
> the open SVN branch for well over 6 months.

I'm more than happy to do the work to back it out, and I will do so in
a way that allows us to easily start using boost again in the future if
we so decide (xorp.ct can currently be compiled with or without boost support
currently).

So, as I'm sure you've noticed, my vote is to not use boost.

Thanks,
Ben

-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com