c++ - Boost/STL 在高性能计算方面是否慢？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开， visit the help center寻求指导。

关闭 11年前。

为 another internet forum quote 致歉，但我觉得这很有趣，想问一下:

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.

我同意取消安全功能，但我看过很多高频招聘广告，他们都要求有 Boost 经验。 Boost 对生成快速代码肯定不是坏事吗？或者这个人只是在理论上说如果你只是在字节级别进行操作会更快？

编辑:引用是关于 STL 和 Boost，因此我添加了 STL 标签。

Answer 1

否

boost 和 C++ 标准库用于生成极快的生产实现。当然，在特定场景中可以改进这些实现——这类似于在您知道自己的执行与通用分配器有何不同以及如何针对该用途进行优化时编写自己的分配器。因此，当然可以分析问题并生成比通用实现(或 boost )更快的优化实现。

当然，任何库也可能被滥用，这可能会导致执行受损。简而言之，boost(大量库)实现是快速实现的绝佳起点。如果您需要它比 boost 更快，请确定问题并加以改进。

许多 C++ 开发人员关心性能；一般来说，比其他语言更多。 boost 通常受到好评，经过同行评审，并且实现用于测试和形成标准库功能的基础。

-----

感谢贾斯汀让我分享他对已结束问题的回答: ^{_{-- 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.