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

Subject: Re: [Boost-users] Boost or Standard when there is the choice?
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2014-02-12 14:50:47

CC: Stephan @ Microsoft, for reason see end of email below.

On 12 Feb 2014 at 9:30, Ahmed Charles wrote:

> > Regarding the micro optimisation remark, I make this purely based on 
> > my experience with Visual Studio where the Dinkumware implementation 
> > almost always outperforms or is similar to a Boost implementation, 
> > especially in VS2013. This is partially because a Boost 
> > implementation usually has a lot more features and therefore a larger 
> > code footprint, but it's also because Dinkumware do a lot of micro 
> > optimisation once code is known stable.
> 
> Since I'm pedantic, I think there's a phenomenon here that you're
> seeing but not ascribing properly. Dinkumware's initial implementation
> tends to not have much concern for performance at all and Boost's solution
> tends to be more mature by the time it's standardized and gets implemented
> by Dinkumware, which usually results in Boost being faster.

So far I agree.

> The reason
> that Microsoft's STL ends up performing better than both Dinkumware's
> and Boost's implementations is because Microsoft cares about performance
> and implements most of the optimizations and because, like you said,
> Boost has more surface area. Microsoft currently cares and they know
> their compiler/platform better.

I agree that Microsoft do a ton of customisation of the Dinkumware 
STL, or rather, they /used/ to do a ton of customisation up till 
VS2013. From my reading of the Dinkumware STL headers, most of the 
customisation was MSVC specific workarounds rather than optimisations 
per se. 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.

> Note: the STL that Dinkumware ships is not the same as the one Microsoft
> ships, so perhaps I'm just being pedantic about naming.

It's pretty close. The BB10 NDK also uses the Dinkumware STL, and it 
was not unheard of for us to compare the two when a bug turned up to 
see our STL had been fixed without us realising.

> As an example, Dinkumware's STL didn't have the make_shared optimization
> that Boost implemented until Microsoft rewrote make_shared to include it.
> That's a case where Boost did better until the standard provider improved
> their implementation. Granted, I don't think shared_ptr is complex enough
> that there is any difference between optimal implementations.

Historically you are right, however Dinkumware's STL had a long head 
start on other STLs in implementing C++11 and indeed, to my 
knowledge, they were the first STL to hit full C++11 standards 
compliance (libc++ wasn't portable until very recently, and I might 
be right in thinking they were slightly later than Dinkumware's).

But I'll tell you what Ahmed, probably neither you nor I are as 
knowledgeable on this as Stephan @ Microsoft, so I've CC-ied him to 
ask these simple questions: (i) how close is vanilla Dinkumware to 
the STL shipped in VS2013 (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, and if yes/no, why in 
your opinion, and is it due to Dinkumware or Boost or other factors?

Niall

-- 
Currently unemployed and looking for work in Ireland.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/