gettimeofday（）是否保证具有微秒级的分辨率？

我正在将一个最初为Win32 API编写的游戏移植到Linux（很好，是将Win32端口的OS X端口移植到Linux）。

QueryPerformanceCounter自程序启动以来，我已经通过提供uSeconds来实现：

BOOL QueryPerformanceCounter(LARGE_INTEGER* performanceCount)
{
    gettimeofday(&currentTimeVal, NULL);
    performanceCount->QuadPart = (currentTimeVal.tv_sec - startTimeVal.tv_sec);
    performanceCount->QuadPart *= (1000 * 1000);
    performanceCount->QuadPart += (currentTimeVal.tv_usec - startTimeVal.tv_usec);

    return true;
}

再加上QueryPerformanceFrequency()恒定的1000000作为频率，可以在我的机器上很好地工作，并为我提供了一个uSeconds自程序启动以来包含的64位变量。

这是便携式的吗？我不想发现以某种方式或类似方式编译内核时，它的工作原理有所不同。我可以将其移植到Linux以外的其他软件上，这很好。

也许。但是你有更大的问题。gettimeofday()如果系统上的某些进程更改了计时器（例如ntpd），则可能导致错误的计时。但是，在“普通” Linux上，我相信的分辨率gettimeofday()为10us。因此，它可以根据系统上运行的进程向前和向后跳转，并可以跳转。有效地回答了您的问题。

您应该查看clock_gettime(CLOCK_MONOTONIC)时间间隔。由于诸如多核系统和外部时钟设置之类的问题，它遇到了一些更少的问题。

另外，查看该clock_getres()功能。

英特尔处理器的高分辨率，低开销时序

如果您使用的是Intel硬件，则以下是读取CPU实时指令计数器的方法。它会告诉您自处理器启动以来执行的CPU周期数。这可能是您可以用来进行性能评估的最细粒度的计数器。

请注意，这是CPU周期数。在Linux上，您可以从/ proc / cpuinfo获取CPU速度，然后除以秒数。将其转换为双精度非常方便。

当我在盒子上运行它时，我得到

11867927879484732
11867927879692217
it took this long to call printf: 207485

这是英特尔开发人员指南，提供了大量细节。

#include <stdio.h>
#include <stdint.h>

inline uint64_t rdtsc() {
    uint32_t lo, hi;
    __asm__ __volatile__ (
      "xorl %%eax, %%eax\n"
      "cpuid\n"
      "rdtsc\n"
      : "=a" (lo), "=d" (hi)
      :
      : "%ebx", "%ecx");
    return (uint64_t)hi << 32 | lo;
}

main()
{
    unsigned long long x;
    unsigned long long y;
    x = rdtsc();
    printf("%lld\n",x);
    y = rdtsc();
    printf("%lld\n",y);
    printf("it took this long to call printf: %lld\n",y-x);
}

@伯纳德：

我不得不承认，您的大多数例子都是直截了当的。它确实可以编译，但是似乎可以正常工作。这对SMP系统或SpeedStep安全吗？

这是一个很好的问题……我认为代码还可以。从实际的角度来看，我们每天都在我的公司中使用它，并且我们运行在各种各样的设备上，所有东西都由2-8个内核组成。当然，是YMMV等，但是它似乎是一种可靠且开销低的（因为它不会使上下文切换到系统空间）计时方法。

通常它是如何工作的：

• 声明代码块为汇编程序（并且是易失性的，因此优化程序将使其保持独立）。
• 执行CPUID指令。除了获取一些CPU信息（我们不做任何事情）之外，它还同步CPU的执行缓冲区，以使时序不受乱序执行的影响。
• 执行rdtsc（读取时间戳）执行。这将获取自重置处理器以来执行的机器周期数。这是一个64位的值，因此，以当前的CPU速度，它将每194年左右一次。有趣的是，在原始的Pentium参考中，他们注意到它每5800年左右就出现一次。
• 最后两行将寄存器中的值存储到变量hi和lo中，并将其放入64位返回值中。

具体说明：

• 乱序执行会导致不正确的结果，因此我们执行“ cpuid”指令，该指令除了为您提供有关cpu的信息外，还会同步任何乱序指令的执行。

• 大多数操作系统在启动时都会同步CPU上的计数器，因此答案在几纳秒内就可以了。

• 休眠注释可能是正确的，但实际上，您可能不在乎跨休眠边界的时间。

• 关于速度变化：较新的Intel CPU补偿速度变化并返回调整后的计数。我快速浏览了我们网络上的某些设备，发现只有一个没有它的设备：运行某些旧数据库服务器的Pentium 3。（这些是linux机器，所以我检查了：grep constant_tsc / proc / cpuinfo）

• 我不确定AMD CPU，我们主要是Intel商店，尽管我知道我们的一些低级系统专家对AMD进行了评估。

希望这能满足您的好奇心，这是一个有趣且（IMHO）尚未充分研究的编程领域。您知道Jeff和Joel在谈论程序员是否应该了解C吗？我对他们大喊：“嘿，忘记那些高级C东西了。如果您想知道计算机在做什么，则应该学习汇编程序！”

您可能对Linux常见问题解答感兴趣clock_gettime(CLOCK_REALTIME)

Wine实际上是使用gettimeofday（）实现QueryPerformanceCounter（）的，众所周知，它可以使许多Windows游戏在Linux和Mac上运行。

启动http://source.winehq.org/source/dlls/kernel32/cpu.c#L312

导致http://source.winehq.org/source/dlls/ntdll/time.c#L448

因此，它明确表示微秒，但未指定系统时钟的分辨率。我想在这种情况下，分辨率意味着将如何增加最小的数量？

数据结构被定义为以微秒为度量单位，但这并不意味着时钟或操作系统实际上能够精确地进行测量。

就像其他人所建议的那样，这gettimeofday()是不好的，因为设置时间可能会导致时钟偏斜并影响您的计算。 clock_gettime(CLOCK_MONOTONIC)是您想要的，clock_getres()它将告诉您时钟的精度。

gettimeofday（）的实际分辨率取决于硬件体系结构。英特尔处理器以及SPARC机器均提供可测量微秒的高分辨率计时器。其他硬件体系结构则取决于系统的计时器，该计时器通常设置为100 Hz。在这种情况下，时间分辨率将不太准确。

我从高分辨率时间测量和计时器（第一部分）获得了此答案

该答案提到了时钟调整的问题。C ++ 11的<chrono>库中同时解决了保证滴答单位的问题和调整时间的问题。

std::chrono::steady_clock保证时钟不被调整，而且时钟将以相对于实时的恒定速率前进，因此诸如SpeedStep之类的技术必须不影响时钟。

您可以通过转换为std::chrono::duration专业化之一来获取类型安全单位，例如std::chrono::microseconds。使用此类型时，刻度值使用的单位没有任何歧义。但是，请记住，时钟不一定具有此分辨率。您可以将持续时间转换为阿秒，而实际上并不需要精确的时钟。

根据我的经验以及通过互联网阅读的内容，答案是“不”，不能保证。它取决于CPU速度，操作系统，Linux的风格等。

在SMP系统中，读取RDTSC是不可靠的，因为每个CPU都维护自己的计数器，并且不能保证每个计数器都相对于另一个CPU同步。

我可能建议尝试clock_gettime(CLOCK_REALTIME)。posix手册指示应在所有兼容的系统上实施。它可以提供十亿分之一秒的计数，但是您可能需要检查clock_getres(CLOCK_REALTIME)系统以查看实际分辨率是多少。