31

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

编辑：实际上最新的优化手册提到了这个指令。它被记录为 <200 个周期，在 Ivy Bridge 上的总带宽至少为 500MB/s。但是关于这条指令的一些更深入的统计数据会很好，因为延迟和吞吐量是可变的。

4

4 回答 4

32

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

IDF 幻灯片中给出了具体平台、时钟速度、Linux 版本和 GCC 版本的详细信息。我不记得头顶上的数字了。有更慢的可用芯片和更快的可用芯片。我们给出的每条指令 <200 个周期的数字是基于每条指令大约 150 个核心周期的测量值。

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

于 2012-06-14T23:32:37.223 回答
7

您可以在英特尔数字随机数生成器 (DRNG) 软件实施指南中找到一些相关信息。

逐字引用如下：

测量吞吐量：

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
于 2012-06-08T07:38:21.227 回答
4

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

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

于 2012-06-10T16:21:29.777 回答
4

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

在 i5-3210M（2.5GHz）Ivybridge（2 核，4 线程）上，4 个线程的峰值为每秒约 9960 万个 64 位 rdrand，相当于每秒约 63.74 亿位。

An 8 threaded i7-3770 (3.4GHz) Ivybridge (4 cores, 8 threads) I hit a peak throughput of 99.6 million 64 bit rdrands a second on 3 threads.

于 2013-04-14T17:01:40.207 回答