使用大型整数对数据集有效地初始化 unordered_map

Question

我有一个巨大的数组（例如，ParticleId[]），由 唯一 个整数（代表粒子 ID）组成，它们以随机顺序存储在内存中。我需要构建一个哈希表来将每个 ID 映射到它在数组中的位置，即从 ID 到索引。 ID 不一定是连续整数，因此简单的查找数组不是一个好的解决方案。

我目前正在使用 c++11 的 unordered_map 容器来实现这一点。使用循环初始化地图：

unordered_map <ParticleId_t, ParticleIndex_t> ParticleHash;
ParticleHash.rehash(NumberOfParticles);
ParticleHash.reserve(NumberOfParticles);
for(ParticleIndex_t i=0;i<NumberOfParticles;i++)
  ParticleHash[ParticleId[i]]=i;

ParticleId_t 和 ParticleIndex_t 只是类型定义的整数。 NumberOfParticles 可以很大（例如，1e9）。就哈希表而言，ParticleId[] 数组和NumberOfParticles 是const。

目前，如上所述构建unordered_map 需要花费大量时间。我的问题是：

1. unordered_map 是这个问题的最佳选择吗？
   • map 的初始化速度是否会更快，尽管它在查找时可能效率不高？
2. 是否可以加快初始化速度？
   • 使用ParticleHash.insert() 是否比使用ParticleHash[]= 快得多？或任何其他功能？
   • 鉴于我的键是唯一整数，有没有办法优化映射以及插入？

我正在考虑使用英特尔concurrent_unordered_map 来并行化它。但是，这会引入对英特尔 TBB 库的依赖，如果可能的话，我想避免这种情况。有没有使用原生 STL 容器的简单解决方案？

更新：

现在我已经恢复到一个普通的排序索引表并依靠bsearch 进行查找。至少表的初始化现在快了 20 倍，并且可以轻松并行化。

Answer 1

似乎构建查找表的应用程序受内存限制，而不是 CPU 限制。这可以通过分析应用程序的原型来验证。这个答案的其余部分假设这是真的。

构建查找表的过程正在获取输入数据的全局视图，这可能会导致大量内存换入/换出磁盘。

如果是这种情况，解决方案是一次处理较小内存块的替代算法。 假设有 100 万个整数。当前进程此时可能正在插入接近 1 的哈希表的低端，而下一刻它可能正在插入接近 100 万的高端。这会导致大量交换。

另一种方法是通过一次处理较小的数据集块来避免交换。我们可以借鉴桶/基数排序的想法。在这种方法中，构建查找表的步骤将由排序步骤代替。桶/基数排序应该在线性时间内运行。数据集中的所有整数都是唯一的这一事实是使用这些排序算法的另一个原因。 如果可以将线性时间排序和交换的最小化结合起来，那可能会提高性能。

Answer 2

我不认为你可以用这个做很多事情，但这里有一些事情可以尝试。

首先，由于您调用的是realloc，因此您无需调用rehash。

insert 可能比operator[] 快​​，因为operator[] 将调用insert 以使用默认值将元素添加到地图，然后将您的值分配给新插入的元素，但优化器可能能够以消除额外的工作。

仅仅因为 keys 是唯一的，这些键的散列值可能不是因为我认为语言规范不要求整数散列返回该整数（描述散列的部分反正模板没说）。

'map' 的初始化可能会更慢，因为它必须在您插入内容时不断重新平衡树，并且查找会更慢。如果您的ParticleID 向量可以重新排列，则可以使用map 的一种替代方法是对向量​​进行排序，然后执行binary_search 以查找ID 的位置并计算索引。但它的性能与map 相似，并且需要重新排列向量。

如果您决定尝试concurrent_unordered_map，由于线程之间的所有内存争用，在 3 或 4 个线程之后您可能不会看到太大的改进。

Answer 3

鉴于“以随机顺序存储的大量唯一整数” - 是否已经有任何东西取决于该随机顺序？如果没有，只需对唯一整数数组进行就地排序，并将唯一整数映射到索引，您可以在数组中执行 std::lower_bound。

如果需要保留大数组的预先存在的顺序，但您在填充该数组后作为一次性步骤构建索引（如您的说明性代码所做的那样），您可以创建一个同样巨大的ParticleId* 和std::sort 数组基于指向的元素（您需要自定义< 指向值的比较）；之后您可以使用std::lower_bound 与相同的< 比较来快速找到特定ParticleId 的巨大数组中的索引。

上述连续数组方法通过以缓存友好的方式使用连续内存极大地提高了性能和内存使用率。

只有当您有大量新的ParticleIds 在您需要能够搜索的时间进入或被删除时，您才需要考虑std::unordered_map。