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/