R在Windows上进行Specter和Meltdown缓解的基准测试
像许多人一样，我怀疑，我有点担心最近的Windows更新是否解决Meltdown和Spectre会对R中的计算时间产生显着的不利影响。我使用大型（ish）数据集进行了很多生存分析，已经需要很长时间了。 不幸的是，它在我更新我的主PC后才发生，因此决定在相关的Windows更新之前和之后使用旧的基准测试进行一次基准测试。 结果非常有趣。
test replications elapsed relative user.self sys.self
Pre-Update 100 287.31 1 281.41 5.68
PostUpdate 100 334.71 1 290.42 44.27
PostUpdate 100 338.9 1 294.22 44.5
经过时间的增加令人烦恼但可管理。 真正令人惊讶的是，这种放缓主要是由于系统时间增加了近8倍。 这是预期的吗？ 有没有其他人做过类似的练习？ 了解其他人正在经历的影响范围将会很有趣，因为我只是通过一种特定类型的计算来做到这一点，这是我工作中的一个瓶颈，而其他计算可能会受到更多影响。 我明白，这是推动类型的问题stackoverflow的目的是，但由于这可能会影响几乎每个人，分享经验的答案可能是有用的。
只是一些背景情况：我用尽可能少的其他进程运行这些测试运行。
为了完整起见，代码运行是：
library("survival")
library("rbenchmark")
set.seed(42)
n = 1e6
censTimes <- seq(from = 0, to = 1, length.out = n)
failTimes <- rweibull(n, 1, -1/log(0.9))
Event <- failTimes < censTimes
obsTimes <- ifelse(Event, failTimes, censTimes)
survObj <- Surv(obsTimes, Event)
Group <- rbinom(n, 4, 0.5)
benchmark(coxph(survObj ~ Group))
感谢您获取一些真实的数字，包括特定的CPU型号和基准代码。
是的，这是有道理的，大多数影响是在system时间由于崩溃缓解。 每个内核/用户空间转换都必须修改页表，导致TLB失效。 内核可能需要接触比R更多的不同页面，因为R可能主要用较少的大分配工作，并且不检查分散在各处的变量/数据结构。
如果Windows也在进行幽灵式的缓解，那么它可能会做得很慢。 IDK，我还没有研究过每个间接分支如何操作系统试图缓解幽灵以外的情况。 （有意使用返回地址预测因子将错误预测报告到已知位置，而不是受到预测因子启动的恶意代码的分支目标注入影响）。
（虽然IDK已经足够让R知道为什么它需要足够的系统调用才能在预更新之前占用很大一部分时间）。
从内核返回到用户空间时页面表失效也会增加用户时间，但用户时间无论如何都是很大的。 （正如我所说的，很可能R不会触及许多不同的页面，所以只需要几个TLB未命中 - >在系统调用或中断之后，页面逐步恢复“达到速度”。）
相关：有关熔毁的更多微架构细节，以及为什么在设计人员认为熔毁攻击之前，CPU设计是有意义的。
链接地址: http://www.djcxy.com/p/86531.html上一篇: R benchmarking of Spectre and Meltdown mitigations on Windows