我找不到关于agner.org指令的延迟或吞吐量的RDRAND的任何信息。但是，这个处理器存在，所以信息必须在那里。
编辑：实际上最新的优化手册提到了这条指令。它被记录为＆lt; 200个周期，Ivy Bridge上的总带宽至少为500MB / s。但是由于延迟和吞吐量是可变的，因此对该指令的一些更深入的统计将是很好的。
答案 0 :(得分：31)
我写了librdrand。这是一组非常基本的例程，它使用RdRand指令用随机数填充缓冲区。
我们在IDF上展示的性能数据来自我编写的测试软件，它在Linux中使用pthreads生成了许多线程。每个线程使用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版本的详细信息。我不记得我头顶的数字了。有些芯片速度较慢，芯片可用速度更快。我们给出的每个指令<200个周期的数量是基于每个指令大约150个核心周期的测量结果。
芯片现已上市，所以任何精通rdtsc使用的人都可以进行同样的测试。
答案 1 :(得分：7)
您可以在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
答案 2 :(得分：4)
以下是我用rdrand获得的一些表现数据：http://smackerelofopinion.blogspot.co.uk/2012/10/intel-rdrand-instruction-revisited.html
在i5-3210M（2.5GHz）Ivybridge（2核，4个线程）上，我获得了每秒约99.6百万64位rdrands的峰值，其中4个线程相当于每秒约6.374亿比特。
8线程i7-3770（3.4GHz）Ivybridge（4核，8个线程）我在3个线程上达到峰值吞吐量99.6百万64位rdrands。
答案 3 :(得分：3)
我使用英特尔的"librdrand"包装器对实际的Ivy Bridge i7-3770进行了一些初步吞吐量测试，它在单核上每秒产生33-35百万32位数。
英特尔的这个70M的数字大约是8个核心;他们报告的只有大约10M，所以我的测试结果好了3倍： - /