为什么随机设备创建成本很高？

Question

C 11支持通过<代码>

我看过多本书，其中提到持续构建和销毁std：：random\u device、std：：uniform\u int\u distribution非常昂贵

为什么创建/销毁这些对象的成本很高？这里的昂贵到底是什么意思？它在执行速度、可执行文件大小或其他方面是否昂贵？

有人能解释一下吗？

Answer 1

简而言之，这取决于系统和库的实现

>

在一个童话般的世界里，你拥有可以想象得到的最糟糕的标准库实现，random\u设备只是一个多余的包装器。我不知道有这样的实现，但有人可能会纠正我这一点

在裸机系统（例如嵌入式微控制器）上，random\u设备可直接与硬件随机数生成器或相应的CPU功能交互。这可能需要也可能不需要昂贵的设置，例如配置硬件、打开通信通道或丢弃前N个样本

很可能您在托管平台上，这意味着具有硬件抽象级别的现代操作系统。让我们在这篇文章的其余部分考虑这个案例

您的系统可能有一个真正的硬件随机数生成器，例如TPM模块可以作为一个。查看Trusted Platform Module如何生成其真实随机数？对该硬件的任何访问都必须通过操作系统，例如在Windows上，这可能是由加密服务提供商（CSP）进行的。

或者您的CPU可能有一些内置指令，例如Intel的rdrand和rdseed指令。在这种情况下，直接映射到这些设备的随机设备只需发现它们可用并检查它们是否可操作即可<例如，代码>rdrand可以检测硬件故障，此时实现可能会提供回退。看看常春藤桥上RDRAND的疲劳特征是什么？

但是，由于这些功能可能不可用，操作系统通常会提供熵池来生成随机数。如果这些硬件功能可用，您的操作系统可能会使用它们来提供此池或在池耗尽后提供后备。您的标准库很可能只是通过特定于操作系统的API访问此池。那么这些的设置开销是多少？

>

传统的POSIX（UNIX）操作系统通过伪设备提供随机数。因此，安装成本与打开和关闭此文件的成本相同。我想这就是你的书所指的

由于这个API有一些缺点，出现了新的API，比如Linux的getrandom。这个库不会有任何安装成本，但如果内核不支持它，它可能会失败，这时一个好的库可以再次尝试

Windows库可能会通过其加密API。因此，要么是旧的CSP API CryptGenRandom，要么是新的CSP API CryptGenRandom。两者都需要服务或算法提供程序的句柄。因此，这可能类似于开发/Uradom方法

在所有这些情况下，您至少需要一个系统调用来访问RNG，并且这些调用比普通函数调用要慢得多。请参阅系统调用开销，甚至rdrand指令的平均指令周期数约为150。请参阅Ivy Bridge上RDRAND指令的延迟和吞吐量是多少？或者更糟，请参阅各种编译器上的RDRAND和RDSEED内部函数？

库（或用户）可能会试图通过缓冲更大数量的随机字节来减少系统调用的数量，例如使用缓冲文件I/O。这将再次使打开和关闭random_device变得不明智，假设这会丢弃缓冲区。

此外，操作系统熵池的大小有限，可能会耗尽，这可能会导致整个系统受到影响（通过使用低于标准的随机数或阻塞直到熵再次可用）。这和缓慢的性能意味着您通常不应该将random_device直接输入到uniform_int_distribution或类似的东西中。相反，使用它来初始化伪随机数生成器。

当然也有例外。例如，如果您的程序在整个运行过程中只需要64个随机字节，那么绘制2.5 kiB的随机状态来初始化mersenne twister将是愚蠢的。或者，如果您需要尽可能最好的熵，例如生成加密密钥，那么可以通过任何方式使用它（或者更好的是，为此使用库；永远不要重新发明加密！）

Answer 2

• 创建random\u设备的成本可能很高。它可能会打开一个向其提供数据的设备，这需要一些时间。调用它也可能很昂贵，因为它需要熵来传递真正的随机数，而不是伪随机数

优势：

• 您通常只使用一个临时的random\u设备，并调用它一次来播种一个PRNG。因此，一次昂贵的创建和调用random\u设备，以及一次昂贵的PRNG种子植入