多年来,CRC32 计算速度越来越快。部分是因为实现优化,也因为新的处理器指令变得可用。因此,这个近十年来的老问题的新答案!
Stephan Brumme 的 CRC32 页面对 2016 年的最后一个优化进行了概述。Yuri Babich 的 FastCRC是 Stephan Brumme 和 Bulat Ziganshin 的快速 C++ CRC32 算法“Slicing-by-16”的 2019 C# 实现。他声称他的版本只比原生 CLI C++ 快速 CRC32 实现慢一点(大约 10%)。该算法是较旧的 CRC-32-IEEE。
如果您有能力选择其他变体,请选择CRC-32C (Castagnoli)。这在 Crc32C.NET 包中可用。
CRC-32C 中的多项式被证明具有更好的错误检测特性,这就是它在较新的标准(iSCSI、SCTP、ext4)中采用的原因。除了更高的可靠性之外,CRC-32C 现在还具有在较新的 Intel 处理器上专用指令的优势。这就是为什么它被选择用于高性能应用程序,例如 Snappy 压缩算法。
Crc32.NET是 Robert Važan 对上述 Crc32C.NET 的 .NET 安全实现,但用于 Crc32 算法。
该库包含对托管代码的优化,因此它确实比其他 Crc32 实现更快。如果您需要 Crc32,这个库是最佳选择。这种实现被调查为从不同的变体中最快的。此外,它对 x64 和 x86 都有好处,因此,似乎没有必要进行 2 种不同的实现。
对于经典的 CRC-32-IEEE 算法,我不知道上面两个 .NET 实现中的哪一个是最快的。性能比较表没有参考第一个实现。
Anonymous Coward 的答案指向crcutil,这是 Andrew Kadatch 和 Bob Jenkins 在 2007 年初发明的新型多字 CRC 算法的高性能 CRC 参考实现。新算法针对现代 Intel 和 AMD 处理器进行了大量调整,并且比几乎快得多所有其他软件 CRC 算法。他们 2010 年的论文《我们所知道的关于 CRC 但害怕忘记的一切》都在下载中列出。本文展示了一些可用于避免重新处理某些数据范围的技巧:
- 增量 CRC 计算
- 更改初始 CRC 值
- CRC的串联
- CRC-ed消息的就地修改
- 在消息之后存储 CRC 值
因此,一旦数据量变得足够大或环境有限时,请尝试明智地计算需要计算的内容。