矢量与地图性能混淆

Question

编辑：我特别将std::vector 的线性 搜索操作与std::map 二进制 搜索操作进行比较，因为这似乎与Herb 的声明有关。我知道使用二分搜索会将性能从 O(N) 提高到 O(log N) 但这不会测试 Herb 的主张

Bjarne Stroustrup 和 Herb Sutter 最近都谈到了std::vector 在人们期望使用std::list 的情况下有多棒，因为在链表遍历期间缓存未命中的成本。 （见 http://channel9.msdn.com/Events/Build/2014/2-661 在 48 分钟标记处）

Herb 进一步声明，对有序向量的操作甚至比 std::map 还要快（参见 http://i.imgur.com/zX07TZR.png，取自上述 channel9 视频的 51:30 标记），我发现这很难理解。所以我创建了一个小测试来证明这一点，但很难重现这些结果：https://ideone.com/MN7DYK

这是测试代码：

template <typename C>
void test(std::string name, std::vector<int> shuffledInputValues, C & c)
{
   // fill container 'c' with values from 'shuffledInputValues' then erase them all
   {
      std::cout << "testing " << name << "..." << std::endl;
      timer t;

      for (auto val : shuffledInputValues) insert(c, val);
      for (auto val : shuffledInputValues) remove(c, val);
  }
}

// output:
// testing vector...99.189ms
// testing deque...120.848ms
// testing set...4.077ms

注意 std::vector 的执行速度比 std::set 慢一个数量级。当然这是我预期的结果，但我对 Herb 试图提出的说法感到困惑。

我做错了什么？还是我误解了 Herb 的说法？

关于我的测试应用的注意事项：

• 它必须使用线性运算 - 练习的重点是演示 CPU 缓存魔法，这是 Herb 和 Bjarne 对练习的约束
• 我没有为向量迭代尝试任何棘手的循环解开，但我相信迭代不会对性能产生太大影响
• 我将循环限制为 10K 项，因为 ideone 在较大的集合上超时，但增加大小不会改变结果

编辑：请参阅https://ideone.com/916fVd 以获取仅比较查找性能的修改示例。线性搜索表现出相同的性能。

Answer 1

在没有源代码以及有关编译器选项、硬件等信息的情况下，当然很难给出准确的答案。

几个可能的区别：

• 我认为演讲者每次都在谈论向量的中间中的插入/删除（而在您的示例中，您总是添加到末尾并从开头删除）；
• 演讲者没有提及如何确定添加/删除哪些项目，但在这种情况下，我们不妨假设做出最小努力来确定这一点：您每次都进行向量访问，而插入值可以很简单地计算（例如，使用低成本的 PNRG 来确定要插入的下一个值）或始终相同，并且对于删除，每次都删除中间元素，因此不需要查找/计算值。李>

但是，正如另一位评论员所提到的，我会拿走一般原则而不是具体的数字/时间。从本质上讲，要传达的信息是：为了评估算法性能/可扩展性，您以为自己了解的“计数操作”在现代系统中不再适用。

Answer 2

我找到了slides 以便于参考（我看不到图表，但我猜这可能是因为专有文件格式）。相关的幻灯片是第 39 号，它描述了正在解决的问题：

§ 生成 N 个随机整数并将它们插入到一个序列中，以便将每个整数按数字顺序插入到适当的位置。

§ 通过在序列中选择一个随机位置并删除那里的元素，一次删除一个元素。

现在，很明显链表不是解决这个问题的好选择。尽管列表在开头或中间插入/删除比向量好得多，但由于需要线性搜索，因此在 随机 位置插入/删除并不好。由于缓存效率更高，使用向量进行线性搜索要快得多。

Sutter 建议地图（或一般的树）似乎是该算法的自然选择，因为您得到 O(log n) 搜索。事实上，对于插入部分中较大的 N 值，它确实很容易击败向量。

但是来了。您需要删除第 n 个元素（对于随机 n）。这就是我认为您的代码作弊的地方。您按照插入的顺序删除元素，有效地将输入向量用作查找表以查找“随机”位置的元素值，以便您可以在 O(log n) 中搜索它。所以你实际上是在使用集合和向量的组合来解决问题。

常规二叉搜索树，例如用于std::map 或std::set（我假设 Sutter 使用）的二叉搜索树没有快速算法来查找第 n 个元素。 Here's one 据称平均为 O(log n)，在最坏的情况下为 O(n)。但是std::map 和std::set 不提供对底层树结构的访问，所以对于那些你被困在有序遍历（如果我错了，请纠正我）的人来说，这又是一个线性搜索！实际上，我很惊讶地图版本与 Sutter 结果中的矢量版本具有竞争力。

对于 log(n) 复杂性，您需要一个结构，例如 Order statistic tree，遗憾的是标准库没有提供这种结构。有 GNU Policy-Based STL MAP，如 here 所示。

这是我为矢量 vs 集合 vs ost 制作的快速测试代码（vs 带有二进制搜索的矢量以获得良好的度量）https://ideone.com/DoqL4H Set 慢得多，而其他基于树的结构比向量快，这与 Sutter 的结果不符。

order statistics tree: 15.958ms
vector binary search: 99.661ms
vector linear search: 282.032ms
set: 2004.04ms

（N = 20000，差异只会更大，有利于具有更大值的ost）

简而言之，我得出了相同的结论，即 Sutter 的原始结果看起来很奇怪，但原因略有不同。在我看来，这次更好的渐近复杂度赢得了更低的常数因子。

请注意，问题描述不排除重复随机值的可能性，因此使用 map / set 而不是 multimap / multiset 有点欺骗 map / set，但我认为只有很小的意义当值域远大于N 时。此外，预先保留向量不会显着提高性能（当 N = 20000 时大约为 1%）。