使用长（64 位）的 CRC 校验和答案

【问题标题】：CRC checksum using long (64 bit)使用长（64 位）的 CRC 校验和
【发布时间】：2012-03-01 14:41:29
【问题描述】：

我检查了 CRC64 的不同实现。例如，this、this 和 this。所有这些的问题在于它们使用字节。但是，在 64 位系统上，我想使用 long（8 字节）。这样，我将需要更少的迭代。例如，对于 128 字节的数据，使用 byte，我需要迭代 128 次，而使用 long，我只需要迭代 16 次。

是否有任何使用long 甚至大于一个字节的字长的 CRC64 实现？可以修改这些方案吗？

【问题讨论】：

如果 SSE 可用，GCC 最有可能展开您的循环，甚至在可能的情况下使用 128 位 XMM 寄存器。因此，在您花费大量时间盲目优化代码之前，请检查您的编译器在做什么。
是的，但是计算是循环的，我认为不能向量化。
在您尝试超越编译器之前，请检查它的智能程度。 GCC 执行许多循环分析，其中一些我相信您从未听说过。即使在循环计算中，它也可以（并且实际上在某些情况下确实可以）展开循环。我并不是说你的情况是这样，但你必须在进行自己的优化之前进行检查。
过早的优化是大量麻烦的根源。始终确保您确实需要更高的性能并且首先您现在拥有的不是最佳...

标签： c checksum

【解决方案1】：

CRC 计算使用一个技巧来避免必须逐位处理数据：它使用一个查找表，允许它一次处理多个位。

同时处理n 位需要大小为2^n 的查找表。您链接的实现一次读取 1 个字节（8 位），实际上它们都使用大小为 256 == 2^8 的查找表。

一次处理 64 位需要大小为 2^64 的查找表，这是不切实际的。这就是为什么 CRC 的常见实现一次只处理 1 个字节的原因。

虽然可以使用 65536 条目数组一次处理 2 个字节，但由于使用更多 CPU 缓存内存，这可能会对性能产生负面影响。

【讨论】：

顺便说一句，你知道查找表是否也用于硬件实现吗？
@Vlad 我对硬件实现了解不多。
@VladLazarenko：有些硬件实现与串行通信相关联并以与波特率相同的速度运行，依次处理每个位，因此不需要查找表。