如何测试 CRC32C 是否是“好”随机生成器？

Question

我最近发现 _mm_crc32_* intel 内在指令可用于生成（伪）随机 32 位数字。

#include <nmmintrin.h> /* needs CRC32C instruction from SSE4.2 instruction set extension */

uint32_t rnd = 1; /* initialize with seed != 0 */

/* period length is 4,294,967,295 = 2^32-1 */
while (1) {
#if 0 // this was faster but worse than xorshift32 (fails more tests)
    // rnd = _mm_crc32_u8(rnd, rnd >> 3);
#else // this is faster and better than xorshift32 (fails fewer tests)
    rnd = _mm_crc32_u32(rnd, rnd << 18);
#endif
    printf("%08X\n", rnd);
}

此方法与 LCG 一样快，并且比 xorshift32 更快。维基百科说，由于 xorshift 生成器“未能通过一些统计测试，因此被指责为不可靠”。

现在我想知道 CRC32C 方法是否通过了对随机数生成器进行的各种测试。我只是通过尝试使用 PAQ8 压缩器（失败）进行压缩来验证每一位，甚至是 LSB，都是“随机的”。有人可以帮我做更好的测试吗？

编辑：使用建议的 TestU01 套件中的测试，我之前使用的方法结果证明比 xorshift32 更差。如果有人有兴趣使用更好的版本，我已经更新了上面的源代码。

Answer 1

衡量 PRNG 好坏的一个指标是周期的长度。如果这对您的应用程序很重要，那么您使用的 CRC-32 将不是一个好的选择，因为周期只有 2³²。一个后果是，如果您使用的样本比这更多（这不会花费很长时间），您的结果将重复。另一个是连续的 CRC-32 值之间存在相关性，其中只有一个可能的值将跟随当前值。

更好的 PRNG 具有指数级更长的周期，并且返回的值小于状态中的位，因此连续值不具有这种相关性。

您不需要使用 CRC-32C 指令来提高速度。此外，您不需要设计自己的 PRNG，这充满了隐藏的危险。最好把它留给专业人士。请参阅 this work 了解高质量、小型和快速的随机数生成器。

Answer 2

视频游戏（尤其是单人游戏）的 PRNG 要求与蒙特卡罗模拟游戏的要求存在很大差异。对于科学数值计算来说，小的偏差可能是个问题，但对于游戏来说通常不是问题，特别是如果来自同一个 PRNG 的数字以不同的方式使用时。

存在具有不同速度/质量权衡的不同 PRNG 是有原因的。

---

这个速度非常快，特别是如果种子/状态保留在寄存器中，在现代 Intel CPU 上只需要 2 或 3 微秒。因此，如果它可以内联到循环中，那就太棒了。与其他任何具有相同速度的东西相比，它可能质量更好。但是与较大状态下仅慢一点的东西相比，如果您关心统计质量，这可能是可悲的。

---

在带有 BMI2 的 x86 上，每个 RNG 步骤应该只需要 rorx edx, eax, 3 / crc32 eax, dl。在 Haswell/Skylake 上，这是 2 微指令，总延迟 = 1 + 3 个周期，用于循环携带的依赖项。 (http://agner.org/optimize/)。或者没有 BMI2 的 3 微秒，对于 mov edx, eax / shr edx,3 / crc32 eax, dl，但在 CPUs with zero-latency mov for GP registers: Ivybridge+ and Ryzen 上仍然只有 4 个延迟周期。

2 uops 对周围代码的影响可以忽略不计，在正常情况下，您对每个 PRNG 结果做了足够的工作，4 周期依赖链不是瓶颈。 （或者如果您的编译器在循环内存储/重新加载 PRNG 状态而不是将其保存在寄存器中并在循环之后将存储下沉到全局，则大约 9 个周期，这会花费您 2 个额外的 1-uop 指令）。

在 Ryzen 上，crc32 是 3 uop，总延迟为 3c，因此对周围代码的影响更大，但如果您对 PRNG 结果做的太少而成为瓶颈，那么每 4 个时钟的瓶颈是相同的。

我怀疑您可能一直在对循环携带的依赖链瓶颈进行基准测试，不是对实际周围代码的影响，这些代码做了足够的工作来隐藏延迟。 （几乎所有相关的 x86 CPU 都是乱序执行的。）使 RNG 比 xorshift128+ 甚至 xorshift128 更便宜，对于大多数用例来说可能是微不足道的好处。 xorshift128+ 或 xorshift128* 速度很快，而且速度相当不错。

---

如果您想要快速获得大量 PRNG 结果，请考虑使用 SIMD xorshift128+ 并行运行两个或四个生成器（在 XMM 或 YMM 向量的不同元素中）。特别是如果您可以有效地使用 PRNG 结果的__m256i 向量。见AVX/SSE version of xorshift128+，也见this answer where I used it。

---

将整个状态作为 RNG 结果返回通常是一件坏事，因为这意味着一个值可以准确地告诉您下一个值是什么。即 3 后面总是跟着 1897987234 （假数字），从不 3 后面跟着别的东西。大多数统计质量测试都应该考虑到这一点，但这对于任何给定的用例来说可能是问题，也可能不是问题。

请注意，https://en.wikipedia.org/wiki/Xorshift 表示即使 xorshift128 也未能通过一些统计测试。我认为 xorshift32 明显更糟。 CRC32c 也是基于 XOR 和 shift（但在 Galois Field(2) 中也具有位反射和模数），因此认为它的质量可能相似或更好是合理的。

您说您选择 crc32(rnd, rnd>>3) 给出了 2^32 的周期，这是您在这么小的状态下可以做的最好的事情。 （当然rnd++ 达到了相同的周期，所以它不是衡量质量的唯一标准。）它可能至少和an LCG 一样好，但那些不被认为是高质量的，特别是如果模数是 2^32（所以你可以从固定宽度的整数数学中免费得到它）。

Answer 3

这是一个有趣的问题。最终，唯一重要的测试是“这个 rng 是否为我正在处理的问题产生正确的结果”。你希望用 rng 做什么？

为了避免针对每个不同的问题回答该问题，我们设计了各种测试。例如，参见 George Marsaglia 设计的“Diehard”测试。在网络上搜索“marsaglia 随机数生成器测试”会发现几个有趣的链接。

我认为 Marsaglia 的作品在这一点上已有几十年的历史了。我不知道从那以后是否有更多关于这个主题的工作。我的猜测是，对于非加密目的，通过 Diehard 测试的 rng 可能就足够了。