使用RDTSC指令测量C中的代码执行时间
我写了一个简单的程序来测量使用RDTSC指令的代码执行时间。 但我不知道我的结果是否正确以及我的代码有什么问题…我不知道如何validation它。
#include #include #include #include #define N (1024*4) unsigned cycles_low, cycles_high, cycles_low1, cycles_high1; static __inline__ unsigned long long rdtsc(void) { __asm__ __volatile__ ("RDTSC\n\t" "mov %%edx, %0\n\t" "mov %%eax, %1\n\t": "=r" (cycles_high), "=r" (cycles_low):: "%rax", "rbx", "rcx", "rdx"); } static __inline__ unsigned long long rdtsc1(void) { __asm__ __volatile__ ("RDTSC\n\t" "mov %%edx, %0\n\t" "mov %%eax, %1\n\t": "=r" (cycles_high1), "=r" (cycles_low1):: "%rax", "rbx", "rcx", "rdx"); } int main(int argc, char* argv[]) { uint64_t start, end; rdtsc(); malloc(N); rdtsc1(); start = ( ((uint64_t)cycles_high << 32) | cycles_low ); end = ( ((uint64_t)cycles_high1 << 32) | cycles_low1 ); printf("cycles spent in allocating %d bytes of memory: %llu\n",N, end - start); return 0; } 在使用RDTSC计时时，您应该记住一些（非显而易见的）问题：
-
它计数的时钟频率可能是不可预测的。 在较旧的硬件上，频率实际上可能在两个RDTSC指令之间发生变化，即使在固定的较新硬件上，也很难分辨它运行的频率。
-
由于RDTSC没有输入，因此CPU本身可能会将RDTSC指令重新排序，以便在您尝试测量的代码之前。 请注意，这与编译器重新排序代码的问题不同，您已使用__volatile__避免了这一问题。 为了有效地避免这种情况，您必须执行序列化指令 ，该指令将阻止CPU在其之前移动指令。 您可以使用CPUID或RDTSCP（这只是RDTSC的序列化forms）
我的建议：只需使用您的操作系统具有的任何高频计时器API。 在Windows上，这是QueryPerformanceCounter，在Unix上，你有gettimeofday或clock_gettime。
除此之外，您的RDTSC代码存在一些结构性问题。 返回类型是“unsigned long long”，但实际上没有返回任何内容。 如果你修复了这个问题，你可以避免将结果存储在全局变量中，并且可以避免编写多个版本。
可能影响您获得的结果的问题是：
-
在大多数现代80×86 CPU上，TSC测量的是固定频率时钟而不是周期，因此同一段代码可能会有很大的不同“周期”，具体取决于电源管理，同一内核中其他逻辑CPU的负载（超线程），其他内核的负载（turbo-boost），CPU温度（热量限制）等
-
没有什么能阻止操作系统的调度程序在第一个
rdtsc();之后立即rdtsc();你的线程rdtsc();导致产生的“循环花费分配”包括CPU花费在执行任意数量的完全不同的进程上的时间。 -
在某些计算机上，不同CPU上的TSC不同步; 并且没有什么能阻止操作系统在第一个
rdtsc();之后立即rdtsc();你的线程rdtsc();然后在完全不同的CPU（具有完全不同的TSC）上运行您的线程。 在这种情况下，end - start可能是负面的（就像时间倒退一样）。 -
没有什么能阻止IRQ（来自硬件）在第一个
rdtsc();之后立即中断你的代码rdtsc();导致产生的“循环花费分配”包括操作系统处理任意数量的IRQ所花费的时间。 -
不可能阻止SMI（“系统管理中断”）导致CPU进入SMM（“系统管理模式”）并在第一个
rdtsc();之后执行隐藏的固件代码rdtsc();导致产生的“循环花费分配”包括CPU花费在执行固件代码上的时间。 -
一些（旧）CPU有一个错误，当较低的32位溢出时
rdtsc给出了狡猾的结果（例如，当TSC从0x00000000FFFFFFFF变为0x0000000100000000时，您可以在错误的时间使用rdtsc并获得0x0000000000000000）。 -
没有什么能阻止“无序”现代CPU重新排列执行大多数指令的顺序，包括你的
rdtsc指令。 -
你的测量包括测量的开销（例如，如果
rdtsc需要5个周期而你的malloc()需要20个周期，那么你报告25个周期而不是20个周期）。 -
有或没有虚拟机;
rdtsc指令可能是虚拟化的（例如，除了常识之外的任何内容都不会阻止内核使rdtsc报告有多少可用磁盘空间或其他任何它喜欢的内容）。 理想情况下，rdtsc应该被虚拟化以防止上面提到的大多数问题和/或防止定时侧通道（但它几乎从不是）。 -
在极端旧的CPU（80486及更早版本）上，TSC和
rdtsc指令不存在。
注意：我不是GCC内联汇编的专家; 但我强烈怀疑你的宏是错误的，编译器可以选择生成这样的东西：
rdtsc mov %edx, %eax ;Oops, trashed the low 32 bits mov %eax, %ebx
应该可以告诉GCC在EDX：EAX中返回值/ s并完全删除两个mov指令。
注意：在我写这篇文章时，我想出了一种更简单/更清晰的方法来校准TSC转换因子。 所以，继续阅读……
如果您愿意，在linux下[其他一些操作系统有类似的东西 – 例如BSD实现了linux / proc的一部分]，在/proc/cpuinfo ，您将看到如下字段：
bogomips : 5306.71 flags : blah blah2 constant_tsc processor : blah
如果您读取此文件，则bogomips是系统引导期间计算的Mhz [sort of]的总CPU频率。 如果您的机器具有速度步长，则cpu Mhz于cpu Mhz 。
要使用bogomips ，请计算processor行数并将bogomips除以它。 注意剥去“。” 并将其视为Khz并使用整数数学。
如果你有constant_tsc ， TSC将始终以这个[最大]频率运行，并且永远不会变化，无论特定核心是否由于速度步长而减慢。
如果读/proc/cpuinfo使您感到娇气，则可以采用另一种方法来校准/确定TSC频率。
请执行下列操作：
tsc1 = rdtsc clk1 = clock_gettime // delay for a while for (i = 1; i < 1000000; ++i) asm volatile ("" ::: "memory"); clk2 = clock_gettime tsc2 = rdtsc
使用这些值，您可以计算TSC频率。 做上面几千次。 采用最小增量 - 这可以防止操作系统时间切掉你的测量值。
对于不会导致时间片的循环计数，请使用最大值。 实际上，您可以使用tv_sec = 0, tv_nsec = 500000 （500 us）的nanosleep替换循环。 nanosleep比nanosleep好得多。 实际上，如果你nanosleep ，你可以在2-3秒内进行nanosleep 。
clk2 - clk2值[转换]为小数秒，为您提供tsc2 - tsc1的校准和TSC滴答和秒的转换。
32位平台有“= A”。 这将创建来自eax和edx的64位结果。 遗憾的是，在64位平台上，它只是意味着rax寄存器，这没有任何帮助。
相反，更好的是，您可以使用“__builtin_ia32_rdtsc（）”内在函数直接返回64位无符号整数。 同样适用于rdtscp（也返回当前核心）。 请参阅gcc手册。 与使用内联asm手动执行相比，它们发出的代码稍微好一些，并且可以在32位和64位之间移植。
如果在/ proc / cpuinfo标志中设置了“constant_tsc”，则无论CPU频率如何缩放，TSC都以恒定速率运行。 如果设置了“nonstop_tsc”，则TSC继续以C（hibernate）状态运行。 如果两者都设置，计数器“应该”也在核心之间同步（至少在最近的CPU，Core i7或更高版本上）。 我对最后一点不太确定，也许有人可以纠正我？