Ivy Bridge 上 RDRAND 指令的延迟和吞吐量是多少？答案

【问题标题】：What is the latency and throughput of the RDRAND instruction on Ivy Bridge?Ivy Bridge 上 RDRAND 指令的延迟和吞吐量是多少？
【发布时间】：2012-05-16 02:00:44
【问题描述】：

我在agner.org 上找不到任何关于RDRAND 指令的延迟或吞吐量的信息。但是，这个处理器是存在的，所以信息必须在那里。

编辑：实际上最新的优化手册提到了这个指令。它被记录为

【问题讨论】：

我不知道答案，没有运行基准测试，但作为感兴趣的一方，我可以问“你希望它有多快？” IE。哪些应用需要大量 RDRAND？顺便说一句，这里有两个单独的问题：（a）指令在延迟和吞吐量方面有多快，以及（b）它的读取速度是否比熵池累积的速度更快？ IE。你能用尽熵池，只用伪随机数吗？
我能想到为什么有人会关心的唯一原因是决定是直接使用RDRAND还是通过PRNG。在这两种情况下，您都会得到相同的可观察行为，但其中一种可能比另一种要快得多，而且还不能立即看出会是哪一种。（KrazyGlew：你的b 有点无关紧要。这就像问你在转换成水之前得到了多少圣水。两者之间没有可察觉的区别，在这种情况下，这种区别基本上没有意义。）
@KrazyGlew 一个用例正在为 GPU 上的统计采样生成随机数。
相关：Is there any legitimate use for Intel's RDRAND? 具有针对 std::mt19937 PRNG 的基准。如果有的话，RDRAND 可能比那个测试慢，因为他们不使用结果（正如大卫的回答所解释的那样，这在 asm 中是有问题的）。
Agner 的测试现在包括 RDRAND 号码。 IvB 吞吐量：每 104-117 个时钟一个。 SKL 吞吐量：每 ~460 个时钟一个。（但大概这取决于核心时钟速度，如果 DRNG 以恒定时钟运行。不过，Agner 在 i7-3770k 上进行了测试，因此 IvB 的时钟不应该非常低，使得 RDRAND 看起来很快。除非它处于空闲状态时钟速度？或者也许他的测试也没有使用结果，并且 IvB 比 SKL 更好地压扁了“死”微指令。）

标签： assembly intel rdrand

【解决方案1】：

您可以在Intel Digital Random Number Generator (DRNG) Software Implementation Guide 找到一些相关信息。

逐字引用如下：

测量的吞吐量：

Up to 70 million RDRAND invocations per second
500+ million bytes of random data per second
Throughput ceiling is insensitive to the number of contending parallel threads

【讨论】：

@user434507 - 包含相关位总是好的。该链接可能会中断，并且该答案将变得毫无意义。这次我已经为你做了这个:)
引用：This has the effect of distilling the entropy into more concentrated samples。太棒了，不是吗？
@ArjunShankar，你说得对，我也考虑过这样做，但文章中还有一些有趣的图表。
70 million invocations per second。时钟速度是多少？这也很重要。
如果有人阅读了最后一条评论，不，因为 DRNG 以 800 MHz 运行，无论 CPU 速度如何（在 Ivy Bridge 上），请参阅 David's answer

【解决方案2】：

我已经使用英特尔的"librdrand" 包装器对实际的 Ivy Bridge i7-3770 进行了一些初步的吞吐量测试，它在单个内核上每秒生成 33-35 百万个 32 位数字。

Intel 的这个 70M 数字大约是 8 个核心；他们只报告了大约 10M，所以我的测试要好 3 倍以上：-/

【讨论】：

你真的用过结果吗？大卫的回答说，如果结果寄存器被简单地覆盖，CPU 会丢弃不完整的rdrand uops。（例如，存储到内存或XOR 将其存储到某个东西中。）

【解决方案3】：

我写了 librdrand。使用 RdRand 指令用随机数填充缓冲区是一组非常基本的例程。

我们在 IDF 上展示的性能数据来自我编写的测试软件，该软件在 Linux 中使用 pthread 生成了许多线程。每个线程使用 RdRand 拉取随机数填充内存缓冲区。该程序测量平均速度，并且可以在改变线程数的同时进行迭代。

由于从每个内核到共享 DRNG 和返回的往返通信延迟比在 DRNG 生成随机数所需的时间长，因此随着线程的添加，平均性能明显提高，直到达到最大值达到吞吐量。 IVB 上 DRNG 的物理最大吞吐量为 800MBytes/s。具有 8 个线程的 4 核 IVB 管理大约 780Mbytes/s 的速度。使用更少的线程和内核，可以实现更少的数量。 500MB/s 的数字有些保守，但当你试图做出诚实的性能声明时，你必须这样做。

由于 DRNG 以固定频率 (800MHz) 运行，而内核频率可能会有所不同，因此每个 RdRand 的内核时钟周期数会有所不同，具体取决于内核频率和同时访问 DRNG 的其他内核的数量。 IDF 演示文稿中给出的曲线是对预期结果的真实表示。整体性能受核心时钟频率的影响不大，但影响不大。线程数占主导地位。

在测量 RdRand 性能以实际“使用”RdRand 结果时应小心。如果你不这样做，I.E.你这样做了.. RdRand R6, RdRand R6,....., RdRand R6 重复了很多次，性能会被认为是人为的高。由于数据在被覆盖之前没有被使用，因此 CPU 流水线在发出下一条指令之前不会等待数据从 DRNG 返回。我们编写的测试将生成的数据写入将在片上缓存中的内存，因此管道会停止等待数据。这也是为什么超线程使用 RdRand 比使用其他类型的代码更有效的原因。

IDF 幻灯片中给出了具体平台、时钟速度、Linux 版本和 GCC 版本的详细信息。我不记得头顶上的数字了。有更慢的可用芯片和更快的可用芯片。我们给出的每条指令

芯片现已上市，因此任何精通 rdtsc 使用的人都可以进行同样的测试。

【讨论】：

请添加 IDF 演示文稿的链接。
"我写了 librdrand" - 'nuf 说。
所以rdrand 就像一个高延迟负载？ Agner Fog 的数据表明 IvB 上每 ~110c 一个吞吐量，或 Skylake 上每 ~460 个周期一个吞吐量。我很好奇rdrand 可以重叠多少计算，因为大多数使用随机数的代码实际上除了生成随机数之外还有很多工作要做。所以我很好奇使用RDRAND而不是像xorshift这样的超快速PRNG，甚至与最快的非随机数生成器：xor eax, eax相比，它会减慢一些实际代码的速度。
您是否从软件流水线中获得了更好的结果？在一些隐藏延迟的缓慢计算之前生成下一次迭代的随机数？还是说这没什么用，因为rdrand本身不能退休，所以卡在ROB里了？

【解决方案4】：

以下是我使用 rdrand 获得的一些性能数据：http://smackerelofopinion.blogspot.co.uk/2012/10/intel-rdrand-instruction-revisited.html

在 i5-3210M (2.5GHz) Ivybridge（2 核，4 线程）上，我在 4 个线程的情况下达到每秒约 9960 万次 64 位 rdrands 的峰值，相当于每秒约 63.74 亿位。

一个 8 线程 i7-3770 (3.4GHz) Ivybridge（4 核，8 线程）我在 3 个线程上达到了每秒 9960 万个 64 位 rdrands 的峰值吞吐量。

【讨论】：

如何调用stress-ng 来获取吞吐量数字？我能做的最好的事情是stress-ng --rdrand 1 --metrics -t 60，但指标（如 BogoMIPS）对我来说不是很有用。