Is Boost/STL slow with regard to high performance computing? [closed]

Question

Apologies for another internet forum quote, but I thought this was interesting and wanted to ask:

C++ is faster if you chuck the "safety" features of programming languages and avoid things like STL, and Boost. In raw bytes to bytes C++ is faster, but then again so is C.

The moment you add the baggage of STL, and Boost you are slower than well written C# code. The advantage that the C# JIT and Java jit have is that those safety features are well optimized. C++ safety features rely on the optimization of the compiler.

Thus if you are not careful with your STL, and Boost code you will have a lame duck of an application.

I agree about ridding of the safety features, but I have seen a lot of high frequency job adverts and they all ask for Boost experience. Surely Boost cannot be something bad to producing fast code? Or is this person merely stating theoretically if you simply manipulated at byte level it would be faster?

Edit : The quote is about STL and Boost, thus I added the STL tag.

Answer 1

No

boost and the C++ standard libraries are used to produce extremely fast production implementations. Of course, one could improve upon those implementations in specific scenarios - this is analogous to writing your own allocator when you know how your execution differs from the general purpose allocators, and how to optimize for that usage. So one can of course analyze the problem and produce an optimized implementation that is faster than the general purpose implementations (or boost).

Of course, any library can also be misused, which could result in compromised execution. The short of it is that boost (a large collection of libraries) implementations are an excellent starting point for fast implementations. If you need it to be faster than boost, determine the problem and improve it.

Many C++ developers are concerned about performance; in general, more than other languages. boost is generally well regarded, peer reviewed, and the implementations are used to test and form the basis for standard library features.

-----

Thanks to Justin for letting me share his answer on the closed question: ^{_{-- Seth}}

Quite the opposite.

Boost is not about safety belts.

Boost is about high level software components, with a high level of abstraction This avoids the usual 'library lock-in' seen with other frameworks/libraries¹.

For example, your Boost Graph library does not require you to switch data structures at all: you can use/adapt any data structure that performs well for your application. In the worst case, you might have to write a traits class to help Boost with the interpretation; It is precisely this trait (common to modern template libraries) that makes Boost perform like nothing else in practice: there won't be as much library impedance mismatch. This is directly in line with C++11's new concepts around threading and move semantics: preventing even the most elementary cases of data copying.

Also, all these libraries honour your own allocator implementations, allowing for unsurpassable memory management performance. You can aligned 128bit int vectors in C# - but you'll have to jump through many many hoops² and, there is no way you can ever make it work with the framework API's.

In C++ you pay only for what you use, and Boost is entirely in that spirit.

Mmmm I think I haven't quite stressed the point enough yet, but I'm done for now.

Let me close by looking at it from the other side: in C# it is much harder to write performant code, because it is much harder to see what's going on behind the scenes.

Once you drop behind the scenes (unsafe mode, IL code) you'll arguably be less safe than in C++, because in C++ there is a transparent policy of what happens where and how. In C# you can't even trust an int* that you got one line ago (because the Garbage Collector might have moved your cheese); There is no telling what the compiler and or the JIT engine will make of your nice generic code³.

In short: you can write bad code just anywhere, but Boost cannot be blamed. STL can only be blamed for insane raw performance⁴.

¹PoCo, Qt, MFC, WTL, whatnot....

²Mono SIMD

³Including numerous areas that are close to pathetic and violate the 'Principle Of Least Surprise' in a big way (example coming when blog back online)

⁴That std::copy will be statically translated in the best implementation based on SSE4, MOVSW or just plain memcpy that money can buy, and yet you don't have to even write a single letter different from copying a istream to a set, so to speak.