为什么在重复调用clock_gettime时会看到400x异常值时序？

Posted 2021-04-03

我试图通过使用物理时钟来测量c ++中某些命令的执行时间，但是我遇到了一个问题，即从计算机上的物理时钟读取测量值的过程可能需要很长时间。这是代码：

#include <string>
#include <cstdlib>
#include <iostream>
#include <math.h>
#include <time.h>

int main()
{
      int64_t mtime, mtime2, m_TSsum, m_TSssum, m_TSnum, m_TSmax;
      struct timespec t0;
      struct timespec t1;
      int i,j;
      for(j=0;j<10;j++){
      m_TSnum=0;m_TSsum=0; m_TSssum=0; m_TSmax=0;
      for( i=0; i<10000000; i++) {
            clock_gettime(CLOCK_REALTIME,&t0);
            clock_gettime(CLOCK_REALTIME,&t1);
            mtime = (t0.tv_sec * 1000000000LL + t0.tv_nsec);
            mtime2= (t1.tv_sec * 1000000000LL + t1.tv_nsec);

            m_TSsum += (mtime2-mtime);
            m_TSssum += (mtime2-mtime)*(mtime2-mtime);
            if( (mtime2-mtime)> m_TSmax ) { m_TSmax = (mtime2-mtime);}
            m_TSnum++;
      }
      std::cout << "Average "<< (double)(m_TSsum)/m_TSnum
            << " +/- " << floor(sqrt( (m_TSssum/m_TSnum  - ( m_TSsum/m_TSnum ) *( m_TSsum/m_TSnum ) ) ) )
            << " ("<< m_TSmax <<")" <<std::endl;
      }
}

接下来我在专用核心上运行它（或者系统管理员告诉我），以避免调度程序将进程移动到后台的任何问题：

$ taskset -c 20 ./a.out

这是我得到的结果：

Average 18.0864 +/- 10 (17821)
Average 18.0807 +/- 8 (9116)
Average 18.0802 +/- 8 (8107)
Average 18.078 +/- 6 (7135)
Average 18.0834 +/- 9 (21240)
Average 18.0827 +/- 8 (7900)
Average 18.0822 +/- 8 (9079)
Average 18.086 +/- 8 (8840)
Average 18.0771 +/- 6 (5992)
Average 18.0894 +/- 10 (15625)

很明显，需要大约18纳秒（在这个特定的服务器上）才能调用clock_gettime()，但是我无法理解为什么“最大”时间似乎要长300到1000倍？

如果我们假设核心真正致力于这个过程并且没有被其他东西使用（可能是也可能不是;当不在专用核心上运行时，平均时间是相同的，但sd / max稍大）还有什么可能导致这些“减速”（缺乏一个更好的名字）？

答案

Why Outliers?

当您在两个clock_gettime调用上迭代1000万次时，有许多软件和硬件相关的原因可能会出现异常事件（以及非异常值变化）。这些原因包括：

• 上下文切换：调度程序可能决定在CPU之间迁移您的进程，即使您将进程固定到CPU，操作系统也可能会定期决定在逻辑CPU上运行其他操作。
• SMT：假设这是在带有SMT的CPU上（例如，在x86上超线程），调度程序可能会定期在兄弟核心上安排一些东西（与你的进程相同的物理核心）。这可能会极大地影响代码的整体性能，因为两个线程正在竞争相同的核心资源。此外，SMT和非SMT执行之间可能存在过渡期，其中没有任何执行，因为当SMT执行开始时核心必须重新占用一些资源。
• 中断：典型系统将至少每秒接收数百个中断，包括网卡，图形设备，硬件时钟，系统定时器，音频设备，IO设备，跨CPU IPI等。尝试一下watch -n1 cat /proc/interrupts，看看你可能认为是一个空闲的系统是如何发生的。
• 硬件暂停：CPU本身可能会因各种原因（例如电源或热量限制）或仅仅因为CPU is undergoing a frequency transition而周期性地停止执行指令。
• System Management Mode：完全不同于操作系统看到和处理的中断，x86 CPU有一种“隐藏中断”，它允许在CPU上执行SMM功能，唯一明显的影响是用于测量实时的周期计数器中的周期性意外跳转。
• 正常的性能变化：您的代码每次都不会以完全相同的方式执行。初始迭代将遭受数据和指令缓存未命中，并且对于诸如分支方向之类的事情具有未经训练的预测因子。即使处于明显的“稳定状态”，您仍可能会受到超出您控制范围的性能差异。
• 不同的代码路径：你可能希望你的循环每次通过1执行完全相同的指令：毕竟，没有什么是真正改变的，对吧？好吧，如果你深入了解clock_gettime的内部结构，你可能会发现一些分支，当发生一些溢出时，或者通过更新等从VDSO比赛中的调整因子中读取时采取不同的路径。

这甚至不是一个全面的列表，但至少应该让你尝试一些可能导致异常值的因素。您可以消除或减少其中一些的影响，但在x86上的现代非realtime2 OS上通常无法完全控制。

My Guess

如果我不得不猜测，基于典型的~8000 ns的异常值，这对于上下文切换中断可能太小，您可能会看到由于TurboBoost比率变化导致的处理器频率缩放的影响。这是一个满口，但基本上现代的x86芯片以不同的“最大涡轮”速度运行，具体取决于活动的核心数量。例如，如果一个核心处于活动状态，我的i7-6700HQ将以3.5 GHz运行，但如果2,3或4个核心处于活动状态，则仅分别为3.3,3.2或3.1 GHz。

这意味着即使您的进程从未中断，任何在另一个CPU上运行的工作都可能导致频率转换（例如，因为您从1个转换为2个活动核心），并且在此类转换期间CPU处于空闲状态在电压稳定的同时进行数千次循环。您可以找到一些详细的数字和测试in this answer，但结果是在测试的CPU上稳定需要大约20,000个周期，非常符合您观察到的~8000纳秒的异常值。有时您可能会在一段时间内获得两次转换，从而使影响加倍，依此类推。

Narrow It Down

获得分发

如果您仍想知道异常值的原因，可以采取以下步骤并观察对异常值行为的影响。

首先，您应该收集更多数据。您应该收集具有合理铲斗尺寸的直方图（例如100 ns，甚至更好的某种类型的几何铲斗尺寸，以便在更短的时间内提供更高的分辨率），而不是仅重新编码超过10,000,000次迭代。这将是一个巨大的帮助，因为你将能够准确地看到时间聚集的位置：完全有可能你有其他效果，而不是你注意到“最大”的6000 - 17000 ns异常值，他们可以有不同的原因。

直方图还可以让您了解异常值频率，您可以将其与可以测量的事物的频率相关联，以查看它们是否匹配。

现在添加直方图代码也可能为定时循环增加更多的差异，因为（例如）你将根据时间值访问不同的缓存行，但这是可管理的，特别是因为时间的记录发生在“定时区域“。

发布特定缓解措施

有了这些，您可以尝试系统地检查我上面提到的问题，看看它们是否是原因。以下是一些想法：

1. 超线程：只需在运行单线程基准测试时在BIOS中将其关闭，这样就可以一举消除整个问题。总的来说，我发现这也导致了细粒度基准差异的巨大减少，因此这是一个很好的第一步。
2. 频率调整：在Linux上，您通常可以通过将性能调控器设置为“性能”来禁用子标称频率调整。如果你正在使用/sys/devices/system/cpu/intel_pstate/no_turbo驱动程序，你可以通过将0设置为intel_pstate来禁用超名义（aka turbo）。如果你有另一个驱动程序，你也可以操纵turbo模式directly via MSR，或者如果其他所有驱动程序都失败你可以在BIOS中执行它。在linked question中，当涡轮增压器被禁用时，异常值基本消失，因此首先要尝试。 假设您实际上希望在生产中继续使用turbo，您可以手动将最大turbo比限制为适用于N个核心的某个值（例如，2个核心），然后使其他CPU脱机，因此最多这些核心数将永远积极点。然后，无论有多少核心处于活动状态，您都可以始终以新的最大涡轮增压运行（当然，在某些情况下，您可能仍会受到功率，电流或热量限制）。
3. 中断：您可以搜索“中断亲和关系”以尝试将中断移入固定核心，并查看对异常值分布的影响。您还可以计算中断的数量（例如，通过/proc/interrupts）并查看计数足以解释异常值。如果你发现特定的定时器中断是原因，你可以探索内核提供的各种“无滴答”（又名“NOHZ”）模式，以减少或消除它们。您也可以通过x86上的HW_INTERRUPTS.RECEIVED性能计数器直接计算它们。
4. 上下文切换：您可以使用实时优先级或isolcpus来防止其他进程在您的CPU上运行。请记住，上下文切换问题虽然通常被定位为主要/唯一问题，但实际上相当罕见：最多它们通常以HZ速率发生（在现代内核上通常为250 /秒） - 但它在少数情况下很少发生调度程序实际上决定在繁忙的CPU上调度另一个进程的空闲系统。如果您使基准测试循环变短，通常几乎可以完全避免上下文切换。
5. 与代码相关的性能变化：您可以使用各种分析工具（如perf）检查是否发生这种情况。您可以仔细设计数据包处理代码的核心，以避免诸如缓存未命中之类的异常事件，例如通过预先触摸缓存行，并且可以尽可能避免使用具有未知复杂性的系统调用。

虽然上述部分内容仅用于调查目的，但其中许多内容都可以帮助您确定导致暂停的原因并减轻它们。

我不知道所有问题的缓解 - 像SMM这样的东西你可能需要专门的硬件或BIOS来避免。

---

1好吧，除非在触发if( (mtime2-mtime)> m_TSmax )条件的情况下 - 但这应该是罕见的（也许你的编译器已经使它无分支，在这种情况下只有一个执行路径）。

2实际上，即使使用硬实时操作系统，您也无法获得“零差异”：某些特定于x86的因素（如SMM模式和DVFS相关的停顿）似乎是不可避免的。

另一答案

taskset命令定义了您的进程的亲和性，这意味着您的进程被限制为在指定的CPU核心上运行。它不会以任何方式限制其他进程，这意味着它们中的任何进程都可以随时抢占您的进程（因为所有进程都可以在您为进程选择的CPU核心上运行）。因此，您的最大读取间隔时间（那些5-25 usec）可能代表CPU上的其他进程或中断运行时间以及上下文切换时间。除了你使用CLOCK_REALTIME可能会受到NTP校正等。要测量时间间隔你应该使用CLOCK_MONOTONIC（或linux特定的CLOCK_MONOTONIC_RAW）。

另一答案

这在现代c ++中要容易得多

#include <chrono>
auto start = std::chrono::steady_clock::now();
.....
auto stop = std::chrono::steady_clock::now();
auto duration = stop - start;

对于非实时操作系统，18纳秒非常快。你真的需要比这更准确地测量一些东西吗？根据我的计算，18ns在4GHz CPU上只有72个时钟周期。