#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)
很明显,调用clock_gettime()需要大约18纳秒(在这个特定的服务器上),但我无法理解为什么“最大”时间似乎要长300到1000倍？
如果我们假设核心真正致力于这个过程并且没有被其他东西使用(可能是也可能不是;当不在专用核心上运行时,平均时间是相同的,但是sd / max稍大)还有什么可能导致这些“减速”(缺乏一个更好的名字)？
解决方法
当您通过两次clock_gettime调用迭代1000万次时,有许多软件和硬件相关的原因可能会出现异常事件(以及非异常值变化).这些原因包括：
>上下文切换：调度程序可能决定在cpu之间迁移您的进程,即使您将进程固定到cpu,操作系统也可能会定期在您的逻辑cpu上运行其他操作.
> SMT：假设这是在具有SMT的cpu上(例如,在x86上超线程),调度程序可能会定期在兄弟核心上安排一些事情(与您的进程相同的物理核心).这可能会极大地影响代码的整体性能,因为两个线程正在竞争相同的核心资源.此外,SMT和非SMT执行之间可能存在过渡期,其中没有任何执行,因为当SMT执行开始时核心必须重新占用一些资源.
>中断：典型系统将至少每秒接收数百个中断,包括网卡,图形设备,硬件时钟,系统定时器,音频设备,IO设备,跨cpu IPI等.尝试观察-n1 cat / proc / interrupts,看看你认为是一个空闲系统的动作是怎么发生的.
>硬件暂停：cpu本身可能会因各种原因(例如电源或热量限制)或仅因为CPU is undergoing a frequency transition而周期性地停止执行指令.
> System Management Mode：完全不同于操作系统看到和处理的中断,x86 cpu有一种“隐藏中断”,允许SMM功能在cpu上执行,唯一明显的影响是周期性意外跳转用于测量真实的周期计数器时间.
>正常的性能变化：您的代码每次都不会以完全相同的方式执行.初始迭代将遭受数据和指令缓存未命中,并且对于诸如分支方向之类的事情具有未经训练的预测器.即使处于明显的“稳定状态”,您仍可能会受到超出您控制范围的性能差异.
>不同的代码路径：你可能希望你的循环每次都执行完全相同的指令1：毕竟,没有什么是真正改变的,对吧？好吧,如果你深入了解clock_gettime的内部结构,你很可能会发现一些分支在发生一些溢出时会采用不同的路径,或者在更新时从VDSO比赛中的调整因子中读取等等.
这甚至不是一个全面的列表,但至少应该让你尝试一些可能导致异常值的因素.您可以消除或减少其中一些的影响,但在x86上的现代非realtime2 OS上通常无法完全控制.
我猜
如果我不得不猜测,基于典型的~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纳秒的异常值.有时您可能会在一段时间内获得两次转换,从而使影响加倍,依此类推.
缩小范围
获得分发
如果您仍想知道异常值的原因,可以采取以下步骤并观察对异常值行为的影响.
首先,您应该收集更多数据.您应该收集具有合理铲斗尺寸的直方图(例如100 ns,甚至更好的某种类型的几何铲斗尺寸,以便在更短的时间内提供更高的分辨率),而不是仅重新编码超过10,000,000次迭代.这将是一个巨大的帮助,因为你将能够准确地看到时间聚集的位置：完全有可能你有其他效果,而不是你注意到“最大”的6000 – 17000 ns异常值,他们可以有不同的原因.
直方图还可以让您了解异常值频率,您可以将其与可以测量的事物的频率相关联,以查看它们是否匹配.
现在添加直方图代码也可能为定时循环增加更多的差异,因为(例如)你将根据时间值访问不同的缓存行,但这是可管理的,特别是因为时间的记录发生在“定时区域“.
发布特定缓解措施
有了这些,您可以尝试系统地检查我上面提到的问题,看看它们是否是原因.以下是一些想法：
>超线程：只需在运行单线程基准测试时在BIOS中将其关闭,这样就可以一举消除整个问题.总的来说,我发现这也导致了细粒度基准差异的巨大减少,因此这是一个很好的第一步.
>频率调整：在Linux上,您通常可以通过将性能调控器设置为“性能”来禁用子标称频率调整.如果您使用的是intel_pstate驱动程序,则可以通过将/ sys / devices / system / cpu / intel_pstate / no_turbo设置为0来禁用超标称(也称为turbo).如果您有其他驱动程序,也可以操作turbo模式directly via MSR,或者如果其他所有驱动程序都失败,您也可以在BIOS中执行此操作.在linked question中,当涡轮增压器被禁用时,异常值基本消失,因此首先要尝试.
假设您实际上希望在生产中继续使用turbo,您可以手动将最大turbo比限制为适用于N个核心(例如,2个核心)的某个值,然后使其他cpu脱机,因此最多这个数量的核心将永远积极点.然后,无论有多少核心处于活动状态,您都可以始终以新的最大涡轮增压器运行(当然,在某些情况下,您可能仍会受到功率,电流或热量限制).
>中断：您可以搜索“中断关联”以尝试将中断移入固定核心,并查看对异常值分布的影响.您还可以计算中断的数量(例如,通过/ proc / interrupts),并查看计数足以解释异常值.如果你发现特定的定时器中断是原因,你可以探索内核提供的各种“无滴漏”(又名“NOHZ”)模式,以减少或消除它们.您也可以通过x86上的HW_INTERRUPTS.RECEIVED性能计数器直接计算它们.
>上下文切换：您可以使用实时优先级或isolcpus来防止其他进程在您的cpu上运行.请记住,上下文切换问题虽然通常被定位为主要/唯一问题,但实际上相当罕见：最多它们通常以HZ速率发生(在现代内核上通常为250 /秒) – 但在大多数情况下它很少见调度程序实际上决定在繁忙的cpu上调度另一个进程的空闲系统.如果您使基准测试循环变短,通常几乎可以完全避免上下文切换.
>与代码相关的性能变化：您可以使用各种分析工具(如perf)检查是否发生这种情况.您可以仔细设计数据包处理代码的核心,以避免诸如缓存未命中之类的异常事件,例如通过预先触摸缓存行,并且可以尽可能避免使用具有未知复杂性的系统调用.
虽然上述部分内容仅用于调查目的,但其中许多内容都可以帮助您确定导致暂停的原因并减轻它们.
我不知道所有问题的缓解 – 像SMM这样的东西你可能需要专门的硬件或BIOS来避免.
1好吧,除非在触发if((mtime2-mtime)> m_TSmax)条件的情况下 – 但这应该是罕见的(也许你的编译器已经使它无分支,在这种情况下只有一个执行路径).
2实际上,即使使用硬实时操作系统,您也无法获得“零差异”：某些特定于x86的因素(如SMM模式和DVFS相关的停顿)似乎是不可避免的.
