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

Question

我找不到有关agner.org指令的延迟或吞吐量的有关RDRAND的任何信息。但是，此处理器存在，因此信息必须在那里。

编辑:实际上，最新的优化手册中提到了此说明。在Ivy Bridge上记录为小于200个周期，并且总带宽至少为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结果时，应格外小心。如果不这样做，即您这样做了。RdRandR6，RdRand R6，....，RdRand R6重复了很多次，性能被人为地提高了。由于在覆盖数据之前不使用数据，因此CPU管道在发出下一条指令之前不会等待数据从DRNG返回。我们编写的测试将结果数据写入内存，该数据将保存在片上缓存中，因此管道会停顿以等待数据。这就是为什么使用RdRand比使用其他类型的代码更有效的原因。

IDF幻灯片中提供了特定平台，时钟速度，Linux版本和GCC版本的详细信息。我不记得那些数字。有较慢的可用芯片和较快的可用芯片。我们给出的每条指令<200个周期的数字基于每条指令大约150个核心周期的测量结果。

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