像许多人一样，我怀疑，我有点担心最近解决Meltdown和Spectre的Windows更新是否会对R中的计算时间产生重大不利影响。 我使用大型数据集进行了相当多的生存分析，这已经花费了很长时间。 不幸的是，我只是在更新我的主 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 倍。 这是意料之中的吗？ 还有其他人做过类似的练习吗？ 了解其他人正在经历的影响范围会很有趣，因为我只使用一种特定类型的计算来做到这一点，这是我某些工作的瓶颈，而其他计算可能会受到更多影响。 我很欣赏这正在推动堆栈溢出所针对的问题类型的界限，但由于这可能影响几乎每个人，答案分享经验可能是有用的。
只是一些背景背景： 我在运行这些测试时尽可能少地运行其他进程。
- 处理器：i5-2500(显然没有微码更新！
- 操作系统：Windows 7，更新前和更新后KB4056897
- R 版本 3.4.3
为了完整起见，代码运行是：
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 型号和基准代码。
是的，由于 Meltdown 缓解，大部分影响都在system时间内是有道理的。 每个内核/用户空间转换都必须修改页表，从而导致 TLB 失效。 内核可能必须比 R 接触更多不同的页面，因为 R 可能主要处理较少的大分配，而不是检查分散在各处的变量/数据结构。
如果Windows也在做Spectre缓解，它可能会做一些非常慢的事情。 IDK，除了为每个间接分支使用repoline之外，我还没有研究操作系统如何尝试缓解Spectre。 (故意使用返回地址预测器对已知位置进行错误预测，而不是受到启动预测因子的恶意代码的分支目标注入)。
(尽管 IDK 对 R 有足够的了解，知道为什么它进行足够的系统调用，即使在更新前也要花费相当多的时间。
从内核返回到用户空间时的页表失效也会增加用户时间，但无论如何用户时间都很大。 (正如我所说，R很可能不会接触很多不同的页面，所以只需要一些TLB遗漏 ->页面遍历就可以在系统调用或中断后恢复"速度"。
相关：关于Meltdown的更多微架构细节，以及为什么在任何人想到Meltdown攻击之前，CPU设计是有意义的。