Re: [Boost-users] Boost or Standard when there is the choice?

Subject: Re: [Boost-users] Boost or Standard when there is the choice?
From: Ahmed Charles (acharles_at_[hidden])
Date: 2014-02-14 00:27:44

----------------------------------------
> From: stl_at_[hidden]
> To: s_sourceforge_at_[hidden]; boost-users_at_[hidden]
> Date: Thu, 13 Feb 2014 07:24:59 +0000
> Subject: Re: [Boost-users] Boost or Standard when there is the choice?
>
> [Niall]
>> When running a diff between VS2013's STL and the vanilla one
>> we had at BlackBerry I saw a large drop in size of the patchset as
>> compared to VS2012. I didn't investigate, so in fairness the cause
>> could be anything.
>
> Probably the elimination of faux variadics.
>
> [Ahmed]
>> As an example, Dinkumware's STL didn't have the make_shared optimization
>> that Boost implemented until Microsoft rewrote make_shared to include it.
>
> This is incorrect (or at least phrased in an ambiguous way; I am objecting to the timing implications). I explained the story at GoingNative 2012, so I can explain it again here.
>

Sorry for being incorrect. I was attempting to relay the story below, but apparently misremembered or misheard it the first time. No offense intended. :)

> First, Boost invented shared_ptr and make_shared. Then Dinkumware implemented shared_ptr and make_shared, which Microsoft picked up (shared_ptr in 2008 SP1, make_shared in 2010). When I saw Dinkumware's implementation of make_shared, which achieved Boost/C++0x's recommended single allocation with a special deleter, I rewrote it (in faux variadics) to use a dedicated control block. While doing so, I paid attention to the layout and developed what I referred to as the "We Know Where You Live" optimization, squeezing out an unnecessary pointer. VC 2010 shipped with 5 control blocks (traditional, deleter, deleter/allocator, make_shared, allocate_shared), which were optimal (except that they did not attempt to compress the storage of provided but empty deleters/allocators; on my todo list). This optimization has been maintained in 2012 and 2013 (now true variadic).
>
> At GN 2012, I observationally determined that both Boost and libstdc++ had not implemented We Know Where You Live, with significant impacts on total memory consumption, so I explained the optimization without code, as a gift to Boost (who gave the world shared_ptr/make_shared). I don't think anyone figured this out before I did, or if they did, they didn't ship it, which is what matters.
>
> Since then, it has been explained to me that Boost paid the cost of an extra pointer as make_shared was implemented "non-intrusively", while libstdc++ accidentally paid an extra pointer (not noticing the control block redundancy). I don't know when Boost implemented the optimization, and whether libstdc++ has yet, but they are both aware, and I hope libc++ is too (I should ask Marshall/Howard).
>
> (Note: make_shared didn't ship in 2008 SP1 as it needed rvalue references, and at no time - even prerelease - did VC have a make_shared that performed two allocations.)
>
> [Ahmed]
>> That's a case where Boost did better until the standard provider improved
>> their implementation.
>
> It's the reverse. See http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/STL11-Magic-Secrets slide 7, comparing VC10 SP1, Boost 1.48.0, and GCC 4.6.1.

Thanks for the link. Unfortunately, I didn't go back to the presentation before sending the mail. :/

> Boost is difficult to beat in correctness and performance for the reason that you mentioned (Boost gets a head start, when their features are standardized), so please, give us credit for this one thing! :-> (And for contributing the optimization back. I didn't have to tell anyone about that.)
>
> [Niall]
>> (i) how close is vanilla Dinkumware to the STL shipped in VS2013
>
> I am unable to answer this question, as I have never seen Dinkumware's vanilla library.
>
> I can tell you that we work closely with Dinkumware, and that (in 2010 and above) what may appear to be Microsoft-specific edits, have actually been sent upstream to Dinkumware's master sources, which are capable of generating drops for Microsoft or other clients (whose existence, but not identity, I am aware of). Between 2005 and 2010 the sources were divergent, which caused difficulty in picking up new features (starting with TR1). Now we can rapidly acquire new features.
>
>> (ii) would you, Stephan, say that the VS2013 STL is likely to be on average
>> better performance than a Boost implementation of some given C++ 11 feature,
>
> It varies. Some regexes we do better, some we do worse (e.g. many alternations). make_shared, we did better, because (oddly enough) I had the luxury of (re)writing it from scratch, without any attempt to be "non-intrusive". Our shared_ptr on ARM is likely to be better than Boost, since we go to the trouble of using weaker-than-SC atomics. Our <atomic> is probably better on 2013 since we've figured out how to use intrinsics for almost everything (and even better in the next major version), although maybe not if you've looked at our intrinsics carefully too. Our threading stuff, we've tried to be fast by powering our futures with ConcRT, but I also know where a few bodies are buried (e.g. call_once).
>
> Correctness-wise is another story (e.g. I need to rewrite <functional>, Boost.Bind is more solid), although I will say that for the type traits, VC is likely to give more correct answers because I can request compiler hooks as I need them (and more importantly, compiler fixes).
>
> Hope this helps,
> STL
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users