英特尔睿频加速的“假脱机时间”是多少？答案

【问题标题】：What is the "spool time" of Intel Turbo Boost?英特尔睿频加速的“假脱机时间”是多少？
【发布时间】：2021-01-22 14:04:21
【问题描述】：

就像涡轮增压引擎由于涡轮加速需要时间而具有“涡轮迟滞”一样，我很好奇英特尔处理器中的“涡轮迟滞”是什么。

例如，我的 MacBook Pro 15" 2018（运行 macOS Catalina 10.15.7）中的 i9-8950HK 通常在空闲时位于 1.3 GHz 左右，但当我运行 CPU 密集型程序时，CPU 频率会飙升至比如说 4.3 GHz 左右（最初）。问题是：从 1.3 到 4.3 GHz 需要多长时间？1 微秒？1 毫秒？100 毫秒？

我什至不确定这取决于硬件或操作系统。

这是在对一些 CPU 密集型代码进行基准测试的背景下运行的，这些代码需要 10 毫秒才能运行。问题是，就在这段 CPU 密集型代码运行之前，CPU 基本上是空闲的（因此时钟速度将下降到 1.3 GHz）。我想知道我的基准测试的哪一部分在 1.3 GHz 下运行，什么在 4.3 GHz 下运行：1%/99%？ 10%/90%？ 50%/50%？甚至更糟？

根据答案，我认为在启动基准测试之前运行一些 CPU 密集型代码作为“加速”TurboBoost 的一种方式是有意义的。这就引出了另一个问题：我应该运行这个“spooling-up”代码多长时间？可能一秒钟就足够了，但是如果我试图将其最小化怎么办——“假脱机”代码运行的安全时间是多少，以确保 CPU 将以最大频率运行主代码执行的第一条指令？

【问题讨论】：

我认为这部分取决于energy_performance_preference（或..._bias）设置你（或你的操作系统）为CPU的硬件频率选择设置。（Linux 问答：What are the implications of setting the CPU governor to "performance"?）。但是，是的，在像你这样的 Skylake 派生 CPU 上远低于 1 毫秒，这让 CPU 可以选择自己的频率，使用激进的 EPP 设置可能需要 10 微秒。
请注意，涡轮频率并不是某些基准测试所需的唯一一种“预热”：如果您的基准测试涉及一个数组，那么在您的定时运行之前先触摸它是个好主意；第一次访问会导致页面错误。更多信息请参见Idiomatic way of performance evaluation?

标签： performance x86 benchmarking intel cpu-speed

【解决方案1】：

在Intel Power Gadget API 的帮助下，我编写了一些代码来检查这一点。它休眠一秒钟（因此 CPU 恢复到最慢的速度），测量时钟速度，在给定的时间内运行一些代码，然后再次测量时钟速度。

我只在运行 macOS Catalina 10.15.7 的 2018 年 15 英寸 MacBook Pro（i9-8950HK CPU）上尝试过这个。在时钟速度测量之间运行的特定 CPU 密集型代码也可能会影响结果（它只是整数吗？ FP？SSE？AVX？AVX-512？），所以不要把这些当作确切的数字，而只是数量级/大致数字。我不知道结果如何转化为不同的硬件/操作系统/代码组合。

在我的配置中空闲时的最低时钟速度为 1.3 GHz。这是我以表格形式获得的结果。

+--------+-------------+
| T (ms) | Final clock |
|        | speed (GHz) |
+--------+-------------+
| <1     | 1.3         |
| 1..3   | 2.0         |
| 4..7   | 2.5         |
| 8..10  | 2.9         |
| 10..20 | 3.0         |
| 25     | 3.0-3.1     |
| 35     | 3.3-3.5     |
| 45     | 3.5-3.7     |
| 55     | 4.0-4.2     |
| 66     | 4.6-4.7     |
+--------+-------------+

因此，1 毫秒似乎是获得任何类型更改的最短时间。 10 毫秒使 CPU 达到其标称频率，从那时起它会慢一些，显然超过 50 毫秒才能达到最大涡轮频率。

【讨论】：

我认为笔记本电脑有非常保守的 CPU 频率提升是有意义的。这是电池还是交流电源？我不知道 MacOS 是否使用硬件 p-state 或者它是否对 CPU 频率进行软件控制（直到“额定”max-non-turbo，此时即使在较旧的 CPU 上也由硬件决定何时实际涡轮）。我的 Arch GNU/Linux i7-6700k 桌面在 1 毫秒内跳到最大值，我很确定，通过硬件 p 状态控制，energy_performance_preference = "balance_performance"。
它使用交流电源。出于好奇，您如何判断您的桌面在 1 毫秒内完成了这项工作？
perf stat ./a.out 显示整个进程的平均时钟速度（使用硬件性能计数器测量周期，除以 CPU 时间），即使是非常短的总时间也显示接近最大涡轮的平均值。此外，我从英特尔的 IDF2015 演示文稿中了解到 Skylake 的硬件 p-state 功能，其中一个要点是对突发性工作负载（如网页渲染）做出非常快速的反应以使其变得活泼，然后迅速恢复为空闲状态。并且板载电源管理微控制器评估数据并在微秒级做出决策。
en.wikichip.org/wiki/… 有该演讲的幻灯片，但不幸的是，演示文稿的音频似乎已经从网络上消失了：/
Slowing down CPU Frequency by imposing memory stress 有一些示例 perf stat 输出用于更长的运行，显示内存绑定工作负载的降频。也不完全是您要问的问题，但Lost Cycles on Intel? An inconsistency between rdtsc and CPU_CLK_UNHALTED.REF_TSC 在不同涡轮级别之间的频率切换期间提供了一些有关性能计数器的详细信息。

【解决方案2】：

Evaluation of CPU frequency transition latency 论文介绍了各种英特尔处理器的转换延迟。简而言之，延迟取决于核心当前所处的状态，以及目标状态是什么。对于经过评估的 Ivy Bridge 处理器 (i7-3770 @ 3.4 GHz)，延迟从 23 (1.6 GH -> 1.7 GHz) 到 52 (2.0 GHz -> 3.4 GHz) 微秒不等。

在Hot Chips 2020 会议上，提出了对未来 Ice Lake 处理器的重大转换延迟改进，这应该会对使用 AVX-512 指令的部分矢量化代码产生重大影响。虽然这些指令不支持像 SSE 或 AVX-2 指令那样高的频率，但使用这些指令的孤岛会导致处理器频率的下降和后续上升。

预热处理器显然是有意义的，“预热”内存也是如此。一秒钟的先前工作负载足以达到最高可用涡轮频率，但是您还应该考虑处理器的温度，这可能会降低频率（如果谈论最新的英特尔之一，实际上是 CPU 核心和非核心频率处理器）。您无法在一秒钟内达到温度限制。但这取决于您想通过基准测量什么，以及是否要考虑温度限制。在谈到温度限制时，请注意您的处理器也有功率限制，这是在应用程序运行期间降低频率的另一个可能原因。

另一个在对代码进行基准测试时应该考虑的因素是它的运行时间非常短。注意运行时间/资源消耗测量的可靠性。我建议人为地延长运行时间（运行代码 10 次并测量总体消耗）以获得更好的结果。

【讨论】：

这是在衡量某事决定过渡后的延迟，对吧？即使使用硬件 P 状态管理，这也只是加载反应时间的一部分（例如，在预 Skyalke 上从额定最大到涡轮增压，或者在 Skylake 上从空闲到涡轮增压如果操作系统放弃控制） .或者，如果操作系统选择将 CPU 频率的软件控制保持在 turbo 范围以下，则从空闲到最高（非 turbo）P 状态的转换可能需要 10 毫秒，例如直到下一个定时器中断或更长时间。实际的转换延迟更像是转换的成本（时钟停止多长时间）。
是的，你是对的，研究使用了用户空间调控器。目标 P-state 由使用的缩放调控器设置，因此我们不再谈论硬件，而是谈论缩放调控器的反应时间。