c++ - 为什么反复调用clock_gettime时会看到400倍的异常时间？

Question

我试图通过使用物理时钟来测量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;
      }
}

接下来，我在专用内核上运行它(或使sysadmin告诉我)，以避免调度程序将进程移至后台的任何问题:

$ 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)

显然，调用clock_gettime()大约需要18纳秒(在此特定服务器上)，但是我不明白为什么“最长”时间似乎要长300到1000倍？

如果我们假设内核确实专用于此过程，并且未被其他人使用(这可能是正确的，也可能不是；当不在专用内核上运行时，平均时间是相同的，但是sd/max会更大) ，还有哪些原因会导致这些“速度变慢”(由于缺少更好的名称)？

Answer 1

为什么是离群值？
有许多与软件和硬件相关的原因，当您在两个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:与OS看到和处理的中断完全不同，x86 CPU具有一种“隐藏中断”，它允许SMM功能在您的CPU上执行，唯一明显的影响是用于测量实际值的周期计数器中的周期性意外跳转时间。

正常的性能差异:您的代码不会每次都以完全相同的方式执行。初始迭代将遭受数据和指令高速缓存未命中的折磨，并对诸如分支方向之类的东西具有未经训练的预测器。即使处于明显的“稳定状态”，您也可能会因无法控制的情况而遭受性能变化的影响。

不同的代码路径:您可能希望循环每次通过1都执行完全相同的指令:毕竟，什么都没有真正改变，对吗？好吧，如果您深入研究clock_gettime的内部结构，则很可能会发现某些分支，这些分支在发生某些溢出或在VDSO竞赛的调整因子中进行读取并进行更新等时，采取不同的路径。

那甚至还不是一个完整的列表，但它至少应该让您了解一些可能导致异常值的因素。您可以消除或减少其中一些的影响，但是在x86上的现代非realtime2操作系统上，通常无法完全控制。
我猜
如果我不得不基于大约8000 ns的典型异常值(对于上下文切换中断而言可能太小)进行猜测，您可能会看到由于TurboBoost比率可变而导致的处理器频率缩放的影响。那是一个令人吃惊的，但是基本上现代的x86芯片以 Activity 的核心数量不同，以不同的“最大加速”速度运行。例如，如果一个内核处于 Activity 状态，我的i7-6700HQ将在3.5 GHz下运行，而在2、3或4个内核处于 Activity 状态时，则分别仅在3.3、3.2或3.1 GHz下运行。
这意味着，即使您的进程从未中断，在另一个CPU上短暂运行的所有工作也可能导致频率转换(例如，因为您从m 1转换为2个 Activity 核心)，并且在这种转换期间，CPU处于空闲状态在电压稳定的情况下持续数千个周期。您可以找到一些详细的数字并测试in this answer，但是结果是，在经过测试的CPU上，稳定大约需要20,000个周期，这与您观察到的约8000纳秒的异常值非常一致。有时您可能会在一段时间内获得两次过渡，从而使影响加倍，依此类推。
缩小范围
获取分配
如果您仍然想了解离群值的原因，可以采取以下步骤，观察对离群值行为的影响。
首先，您应该收集更多数据。不仅要对超过10,000,000次迭代的最大值进行重新编码，还应收集具有合理的存储桶大小(例如100 ns，甚至更好的某种类型的几何存储桶大小，可以在更短的时间内提供更高的分辨率)的直方图。这将是巨大的帮助，因为您将能够准确地看到时间在何处聚类:除了用“max”记下的6000-17000 ns离群值之外，还可能有其他影响，并且它们可以具有不同的原因。
直方图还可以让您了解异常频率，您可以将其与可以测量的事物的频率相关联，以查看它们是否匹配。
现在，添加直方图代码还可能会给时序循环带来更多变化，因为(例如)您将根据时序值访问不同的缓存行，但这是可以管理的，尤其是因为时间记录发生在“定时区域”。
发行特定的缓解措施
有了这些，您可以尝试系统地检查我上面提到的问题，以查看是否是引起问题的原因。这里有一些想法:

超线程处理:只需在运行单线程基准测试时在BIOS中将其关闭，即可一口气消除整个问题。总的来说，我发现这也导致细粒度基准方差的大幅减少，因此这是一个很好的第一步。

频率缩放:在Linux上，通常可以通过将性能调节器设置为“性能”来禁用次名义频率缩放。如果您使用的是/sys/devices/system/cpu/intel_pstate/no_turbo驱动程序，则可以通过将0设置为intel_pstate来禁用 super 名词(又名Turbo)。如果您有其他驱动程序，也可以操作Turbo模式directly via MSR；如果其他所有驱动程序都失败，则可以在BIOS中进行操作。在linked question中，禁用turbo时，异常值基本上消失了，因此首先要尝试一下。
假设您实际上一直想在生产中继续使用Turbo，则可以将最大Turbo比率手动限制为适用于N个内核(例如2个内核)的某个值，然后使其他CPU脱机，这样最多可以有多少个内核积极点。这样，无论有多少个内核处于 Activity 状态，您都可以始终在新的max turbo上运行(当然，在某些情况下，您可能仍然会受到功率，电流或热量限制)。

中断:您可以搜索“中断相似性”以尝试将中断移入/移出固定核心，并查看对异常值分布的影响。您还可以计算中断次数(例如，通过/proc/interrupts)，并查看该计数足以解释异常值。如果您发现计时器中断是具体原因，则可以探索内核提供的各种“tickless”(也称为“NOHZ”)模式来减少或消除它们。您也可以通过x86上的HW_INTERRUPTS.RECEIVED性能计数器直接对它们进行计数。

上下文切换:您可以使用实时优先级或isolcpus来防止其他进程在您的CPU上运行。请记住，上下文切换问题虽然通常被定位为主要问题/唯一问题，但实际上却很少见:至多它们通常以HZ速率(在现代内核中通常为250/秒)发生-但在大多数情况下很少见调度程序实际上决定在您繁忙的CPU上调度另一个进程的空闲系统。如果使基准测试循环更短，则通常几乎可以完全避免上下文切换。

与代码有关的性能差异:您可以使用perf等各种配置工具来检查这种情况是否正在发生。您可以仔细设计数据包处理代码的核心，例如通过预先触摸缓存行来避免诸如缓存未命中之类的异常事件，并且可以避免使用复杂性未知的系统调用。

尽管上述某些内容纯粹是出于调查目的，但其中许多内容既可以帮助您确定是什么原因导致暂停，也可以减轻暂停时间。
但我不知道所有问题的缓解措施-像SMM之类的东西，您可能需要专门的硬件或BIOS来避免。

1好吧，除了可能在触发if( (mtime2-mtime)> m_TSmax )条件的情况下-但这应该很少(也许您的编译器使其变为无分支的，在这种情况下，只有一条执行路径)。
2实际上，即使使用硬实时操作系统也无法达到“零方差”:某些x86特定的因素(如SMM模式和DVFS相关的停顿)似乎是不可避免的。