0

我正在阅读这篇文章：

https://stackoverflow.com/a/3183607/997112

这是对 C++ 和 C# 之间性能问题的回答。海报来自高频交易背景，并说他为 HF 工作编写了自己的类库，因为他正在寻找纳秒级的节省。在他的帖子中，他提到他很少使用 C++ STL——这让我很吃惊。

我的问题是 - C++ STL 在性能方面是完全优化的，还是只针对普通用户进行了优化？用 C 语言在原生数组周围包装一些函数会比说 Vector 或 List 更快吗？boost 中有没有性能更好的容器？

我很欣赏这些课程对于 99% 的用户来说足够快——但我的问题是针对其他 1% 的用户。

4

3 回答 3

6

由于多种原因，这个问题不会得到任何说明“STL 是最佳的”的答案：

  1. 至少有六种 STL 实现，其中肯定有一些未优化，而另一些则已优化（但请参阅下一项）。
  2. 您所做的大多数优化都会对使用模式做出假设，并且会对某些使用模式感到悲观。要真正针对特定用例进行优化，需要了解如何使用某些东西。
  3. 大多数 STL 用户以一种或另一种形式滥用组件，并且某些正确使用仅在 C++ 2011 中得到真正支持（例如，使用本地自定义分配器）。
  4. 当人们谈论 STL 时，他们通常指的是使用算法运输的示例容器。虽然有用，但 STL 的重点是算法，这些算法有更好的优化机会。毕竟，STL 的全部意义在于您可以轻松地将算法与自定义创建的容器一起使用！为什么要费心优化容器？但是，请注意，项目 1 到 3 也适用于算法。
  5. STL 有一个很好的抽象，但不是很“有”。特别是，当组合多种算法时，存在比单独应用算法更好的方法，但 STL 接口并不真正支持这一点。

综上所述，要提出比典型的优化 STL 实现更好的东西需要相当多的努力。我会质疑任何人的断言，例如，std::vector<T, A>在一天内编写了一个替换 for 并声称对于典型用例std::vector<T, A>（指可以合理使用分配器的 C++ 2011 版本）更快。

于 2012-11-28T00:19:10.143 回答
2

从实际阅读帖子中，这一点很突出：

“所有自定义同步类仅在空时同步，自定义分配器，自定义无锁队列和列表，偶尔的 STL（带有自定义分配器），但更常见的是自定义侵入式集合（其中我有一个重要的库）。 ”

STL 是为处理读取的多个线程而设置的，但当然需要锁和其他同步原语来处理多个写入者。如果作者真的编写了自定义的无锁队列和列表，那么它可能会比带锁的纯 STL 提供相当大的性能提升。同样几乎可以预期自定义分配器，默认值std::allocator<T>是已知的“中间道路”类型的解决方案。根据分配模式，使用带有内存池的分配器可以提供显着的加速。

于 2012-11-28T00:34:22.210 回答
2

C++03 在复制方面有一个非常明显的性能问题，但在 C++11 中通过移动语义和完美转发解决了这个问题。

该规范定义了所有标准算法的复杂性，因此您可以期待所有实现的特定性能行为。

通常当人们抱怨 stdlib 性能时，他们使用了错误的工具来完成这项工作，只需要改进他们的算法。C++ 提供了很多东西，但它从不假装一件事适用于所有事情。

我发现 stdlib 集合缺少两件事：

当您想要从池或竞技场中分配集合时。分配器（甚至是有状态的）只是不够灵活，无法在所有情况下以零开销完成此操作。

此外，有时实现某些东西的最有效方法是合并两个集合。一个例子是缓存，您可能希望分别合并 anunordered_map和 alist用于查找和 LRU。标准集合并没有使这非常有效。

在这两种情况下，Boost Intrusive 都提供了所需的功能。

于 2012-11-28T00:24:20.317 回答