在 Win32 中，有没有办法获得唯一的 cpu 循环计数或类似的东西，这对于多个进程/语言/系统/等来说是统一的。
我正在创建一些日志文件，但必须生成多个日志文件，因为我们托管的是 .NET 运行时，并且我想避免从一个到另一个调用来记录。因此，我想我只需生成两个文件，将它们合并，然后对它们进行排序，以获得涉及跨世界调用的连贯时间线。
但是，GetTickCount 不会随着每次调用而增加，因此这并不可靠。有没有更好的号码，以便我在排序时按正确的顺序接听电话？
编辑：感谢 @Greg 让我走上了 QueryPerformanceCounter 的轨道，它成功了。
【问题讨论】：
标签： winapi timer cpu-cycles
Heres an interesting article! 表示不使用 RDTSC，而是使用 QueryPerformanceCounter。
结论：
使用普通的旧
timeGetTime()来做 很多时间都不可靠 基于 Windows 的操作系统 因为系统的粒度 定时器可高达10-15 毫秒，意思是timeGetTime()只准确到 10-15 毫秒。 [请注意， 高粒度发生在基于 NT 的 Windows NT 等操作系统， 2000 和 XP。 Windows 95 和 98 趋于 有更好的粒度， 大约 1-5 毫秒]但是，如果您调用
timeBeginPeriod(1)开头 你的程序（和timeEndPeriod(1)at 最后），timeGetTime()通常会 精确到1-2毫秒， 并将为您提供极 准确的时间信息。
Sleep()的行为类似；长度Sleep()实际睡觉的时间 for 与timeGetTime()的粒度，所以之后 拨打timeBeginPeriod(1)一次，Sleep(1)实际上会睡 1-2 毫秒，Sleep(2)为 2-3，依此类推 on（而不是增量睡眠 高达 10-15 毫秒）。用于更高精度的计时 （亚毫秒精度），你会 可能想避免使用 汇编助记符 RDTSC，因为它是 难以校准；相反，使用
QueryPerformanceFrequency和QueryPerformanceCounter，分别是 精确到小于 10 微秒 （0.00001 秒）。对于简单的计时，timeGetTime 和 QueryPerformanceCounter 运作良好， 和 QueryPerformanceCounter 是 显然更准确。然而，如果 你需要做任何类型的“定时 暂停”（例如那些必要的 帧率限制），你需要 小心坐在循环调用中 查询性能计数器，等待 达到一定值；这会 吃掉 100% 的处理器。 相反，考虑一个混合方案， 你在哪里调用 Sleep(1) （不要忘记 timeBeginPeriod(1) first!) 任何时候 你需要通过超过 1 毫秒 时间，然后只输入 QueryPerformanceCounter 100%-busy 循环 完成最后一个
【讨论】：
您可以使用RDTSC CPU 指令（假设 x86）。该指令提供 CPU 周期计数器，但请注意，它会很快增加到最大值，然后重置为 0。正如 Wikipedia 文章所述，您最好使用 QueryPerformanceCounter 函数。
【讨论】：
System.Diagnostics.Stopwatch.GetTimestamp() 返回自时间起源以来的 CPU 周期数（可能是计算机启动时，但我不确定），我从未见过它在 2 次调用之间没有增加。
CPU 周期将特定于每台计算机，因此您不能使用它来合并两台计算机之间的日志文件。
【讨论】：
RDTSC 输出可能取决于当前内核的时钟频率，这对于现代 CPU 来说既不是恒定的，在多核机器中也不是一致的。
使用系统时间，如果处理来自多个系统的提要，则使用 NTP 时间源。您可以通过这种方式获得可靠、一致的时间读数；如果开销对于您的目的来说太多，使用HPET 计算自上次已知的可靠时间读数以来经过的时间比单独使用 HPET 更好。
【讨论】：
在合并日志文件时使用 GetTickCount 并添加另一个计数器。不会为您提供不同日志文件之间的完美顺序，但它至少可以使每个文件中的所有日志保持正确的顺序。
【讨论】：