如何提高 C 程序中的拼写检查时间？

Question

作为哈佛 CS50 课程的一项作业，学生的任务是创建一个拼写检查程序。任务的主要推动力是速度——纯粹的速度——我已经达到了击败员工执行力的地步，但我觉得我可以做得更好，并且正在寻找正确的方向。

这是我的伪代码：

// read the dictionary word list
Read entire dictionary in one fread into memory
rawmemchr through and pick out the words
send each word through the hash function
create chain links for any index where collisions occur

// accept the incoming test words
Run the test word through the hash function
compare to the existing table / linked list
return the result of the comparison

拥有 150K 单词的字典，输入文本高达 6MB，我能够在大约半秒内准确地进行拼写检查。

但是，当我查看来自输入文本的单词时，很明显这些单词中有很大一部分是常见的（例如“the”、“and”、“for”），而且大部分拼写错误的单词也会被检查多次。

我的直觉说我应该能够“缓存”“好命中”和“坏命中”，这样我就不会一遍又一遍地散列相同的单词以进行表查找。尽管当前结果非常接近 O(1)，但我觉得通过重新评估我的方法，我应该能够将时间缩短几微秒。

例如，在我加载了字典之后，输入的文本可能只有 8MB，只有这个：“拼写错误”。因此，与其一遍又一遍地散列/检查同一个单词（以计算为代价），我想了解是否有一种方法可以以编程方式丢弃已经被散列和拒绝的单词，但以一种比哈希/检查本身。 （我正在使用 MurmurHash3，fwiw）。

我意识到理论上的性能改进将仅限于输入文本很长并且存在大量重复拼写错误的情况。根据我评估的一些输入文本，以下是一些结果：

Unique Misspellings: 6960
Total Misspellings:  17845
Words in dictionary: 143091
Words in input text: 1150970
Total Time:          0.56 seconds

Unique Misspellings: 8348
Total Misspellings:  45691
Words in dictionary: 143091
Words in input text: 904612
Total Time:          0.83 seconds 

在第二个示例运行中，您可以看到对于每个拼写错误的单词，我必须返回哈希表大约 5.5 次！这对我来说似乎很疯狂，我觉得必须有一种更有效的方法来解决这种情况，因为我的程序大部分时间都花在了哈希函数上。

我可以实现 Posix 线程（这在 8 核系统上运行）以缩短程序的时间，但我更感兴趣的是围绕该问题改进我的方法和思考过程。

抱歉，这太啰嗦了，但这是我在 Stack Overflow 上的第一篇文章，我正在努力做到彻底。我在发布之前进行了搜索，但大多数其他“拼写检查”帖子都与“如何”而不是“改进”有关。我很感谢您提出的建议，这些建议让我朝着正确的方向前进。

http://github.com/Ganellon/spell_check

Answer 1

在您的两次试验中，值得注意的是大多数单词拼写正确。因此，您应该专注于优化字典中单词的查找。

例如，在您的第一次试验中，只有 1.5% 的单词拼写错误。假设查找一个不在字典中的单词平均需要两倍的时间（因为需要检查桶中的每个单词）。即使您将其降低到 0（理论上的最小值 :)），您的程序速度也会提高不到 3%。

一种常见的哈希表优化是将找到的键移到存储桶链的开头，如果它不存在的话。这将倾向于减少检查常用词的哈希条目的数量。这并不是一个巨大的加速，但在某些键的查找频率比其他键高得多的情况下，它肯定会被注意到。

通过减少哈希表占用来减少链长度可能会有所帮助，但会以更多内存为代价。

另一种可能性，因为一旦构建字典就不会修改它，是将每个桶链存储在连续的内存中，没有指针。这不仅会减少内存消耗，还会提高缓存性能，因为由于大多数单词都很短，所以大多数存储桶都可以放在单个缓存行中。

而且由于单词往往很短，因此您很可能能够找到一种优化比较的方法。 strcmp() 进行了很好的优化，但通常针对较大的字符串进行了优化。如果您被允许使用它，SSE4.2 PCMPESTRI 操作码将非常强大（但弄清楚它的作用以及如何使用它来解决您的问题可能会浪费大量时间）。更简单地说，您应该能够同时比较四个 8 字节前缀和 256 位比较操作（甚至可能有 512 位操作可供您使用），因此通过巧妙的数据排列，您很可能能够做整个桶的并行比较。

这并不是说哈希表一定是解决这个问题的最佳数据结构。但是请记住，您在单个缓存行中可以执行的操作越多，您的程序运行速度就越快。链表密集型数据结构即使在纸面上看起来不错，也可能不是最理想的。

---

在考虑了这个问题几天并实际编写了一些代码之后，我得出的结论是，对于成功的哈希表查找速度进行优化可能不正确对于现实世界的拼写检查器。确实，被查找的文本中的大多数单词通常拼写正确——尽管这取决于拼写检查用户——但试图建议正确拼写的算法可能会在可能的拼写错误中循环执行很多不成功的查找.我知道这可能超出了这个问题的范围，但它确实对优化产生了影响，因为你最终会得到两种完全不同的策略。

如果您想快速拒绝，则需要大量可能为空的桶链，或者布隆过滤器或其道德等价物，这样您就可以在第一次探测时拒绝大多数错误。

例如，如果你有一个很好的哈希算法，它产生的比特比你需要的多——而且你几乎肯定会这样做，因为拼写检查字典没有那么大——那么你可以在hash 用于辅助散列。甚至不必费心去实现整个 Bloom 过滤器，您只需向每个存储桶标头添加一个 32 位掩码，表示存储在该存储桶中的值中五个辅助哈希位的可能值。结合稀疏表——我在实验中使用了 30% 的占用率，这并不是那么稀疏——你应该能够拒绝 80-90% 的查找失败而不超出存储桶标题。

另一方面，如果您尝试优化以获得成功，那么可能会证明较大的存储桶会更好，因为它会减少存储桶标头的数量，从而提高缓存使用率。只要整个存储桶适合一个缓存行，多重比较的速度就会如此之快，以至于您不会注意到差异。 （而且由于单词往往很短，所以 64 字节的缓存线可以容纳五六个字是合理的。）

不管怎样，不用做太多工作，我就能在 70 毫秒的 CPU 中完成一百万次查找。多处理可以大大加快运行时间，特别是考虑到哈希表是不可变的，因此不需要锁定。

我想从中汲取的道德：

为了优化：

• 您需要了解您的数据

• 您需要了解您的预期使用模式

• 您需要根据上述情况调整您的算法

• 你需要做很多实验。

Answer 2

您可能会探索的一些见解/想法：

• 如果值的长度相似 - 或略大于指针 - 封闭式散列将比任何开放式散列（即单独的链接方法）提供更好的性能

• 检查单词的长度是一种便宜的（如果您要跟踪它，可能是免费的）方式，您可以将验证定向到最适合该单词长度的方法

  • 为了将更多的单词放到更少的内存页面上（从而对缓存更加友好），您可以尝试使用多个哈希表，其中存储桶的大小调整为其中的最长文本长度

    李>

  • 4 字节和 8 字节存储桶方便地允许单指令对齐的 32 位和 64 位值比较，如果您使用 NUL 填充字符串（即您可以合并 uint32_t 和char[4]，或uint64_t和char[8]，并比较整数值）。

  • 您选择的哈希函数很重要：多试几次

  • 您选择的碰撞处理策略也很重要：具有线性、二次和可能的素数列表（1、3、7、11...）的轮廓。

  • bucket 的数量是一种平衡行为：太少，你有太多的冲突，太多的 bucket，你有更多的内存缓存未命中，因此使用一系列值进行测试以找到最佳设置

• 您可能会使用更避免碰撞的素数存储桶进行分析，其中 % 将哈希值折叠到存储桶索引范围内，而不是使用两个存储桶计数的幂，您可以使用更快的 & 位掩码

• 上述许多相互作用：例如如果您使用强哈希函数，则对质数桶的需求较少；如果您的碰撞次数较少，您就不需要通过备用存储桶进行复杂的碰撞后搜索顺序

• 拼写检查很容易通过线程进行扩展，因为您正在执行只读哈希表查找；事先将字典插入到哈希表中 - 虽然使用上述多个表提供了一种并行化方法，但情况较少

Answer 3

这是一个很好解决的问题。 ;-) 您应该研究一个名为trie 的数据结构。 trie 是由单个字符构建的树，因此 path 表示信息。每个节点都由您可以合法添加到当前前缀的字母组成。当一个字母是一个有效的单词时，它也会被记录下来。

四个字：

root-> [a]-> [a]-> [r]-> [d]-> [v]-> [a]-> [r]-> [k*]->[s*]
             [b]
                \> [a]-> [c]-> [i*]
                               [u]-> [s*]

这将代表“土豚”、“土豚”、“算盘”和“算盘”。节点是垂直连续的，所以第 2 个字母 [ab] 是一个节点，第 5 个字母 [i*u] 是一个节点。

逐个字符遍历trie，并在点击空格时检查有效单词。如果你不能用你拥有的字符遍历，那么这是一个坏词。如果你在点击空格的时候没有找到valid，那就是一个坏词。

这是 O(n) 的处理时间（n = 字长），而且非常非常快。构建 trie 会消耗大量 RAM，但我认为你不在乎。