与许多人一样，我怀疑，我有点担心最近的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))
答案 0 :(得分：1)
感谢您获得一些实数，包括特定的CPU型号和基准代码。
是的，由于Meltdown缓解，大部分影响都在system时间。每个内核/用户空间转换都必须修改页表，导致TLB失效。内核可能必须触及比R更多的页面，因为R可能主要使用较少的大分配，而不是检查散布在各处的变量/数据结构。
如果Windows也在做Spectre缓解，那么它可能会做很慢的事情。 IDK，我还没有研究过OSes如何尝试减轻除with a retpoline for every indirect branch以外的幽灵。 （故意使用返回地址预测器对已知位置进行错误预测，而不是通过引发预测变量的恶意代码进行分支目标注入）。
（尽管IDK足够了解R，知道它为什么会进行足够的系统调用，甚至在更新前花费很长时间。）
从内核返回到用户空间时页表失效也会增加用户时间，但无论如何用户时间都很长。 （正如我所说的，R很可能没有触及许多不同的页面，所以只需要一些TLB未命中 - ＆gt;页面走动以在系统调用或中断后“恢复速度”。）
相关：more microarchitectural details about Meltdown，以及为什么CPU设计在任何人想到Meltdown攻击之前都有意义。