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

Question

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

编辑:实际上最新的优化手册提到了这条指令.它记录为<200个周期,Ivy Bridge上的总带宽至少为500MB/s.但是由于延迟和吞吐量是可变的,因此对该指令的一些更深入的统计将是很好的.

Answer 1

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

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

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

Answer 2

您可以在英特尔数字随机数发生器(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