windows - 具有可变时钟速度的多核系统中的QueryPerformance计数器

根据MSDN文章Game Timing and Multicore Processors，据说QueryPerformanceFrequency()和QueryPerformanceCounter()函数是最好的。但是在不支持的情况下，我可以使用timeGetTime()或仅使用GetTickCount()。

QueryPerformanceFrequency()是否与CPU时钟相同，或者它使用自己的时钟还是频率不随时间变化的东西？

如果频率随时间随机变化(特别是在笔记本电脑中)

如何使用SetThreadAffinityMask函数？ (我见过的某些代码使用该函数将其更改为“1”，然后使用计数器并将掩码再次更改为旧值。为什么？是否正确？)

仅使用QueryPerformanceFrequency()函数一次并通过案例/问题1中的频率除以计算增量时间值是否正确？还是由情况2解决？

最佳答案

基本实现的QPC千差万别。在某些情况下是，但通常不是。

这将影响RDTSC，但不会影响QPC。

这是为了防止线程从一个CPU内核移动到另一个。这可能有助于避免高分辨率定时方法报告负时间流逝(它发生...)。虽然一般不建议。

QPC的频率是恒定的。至少在给定的系统上，至少直到重新启动为止。

但是您不一定要问正确的问题...

Windows上四个常用的计时功能是:
GetTickCount，timeGetTime，QueryPerformanceCounter(QPC)和RDTSC

我的建议包括:

游戏逻辑计时应使用timeGetTime完成。它简单，可靠，并且为此目的具有足够的分辨率。 (编辑:默认分辨率各不相同-您可以调用timeBeginPeriod将其强制为1毫秒分辨率)

不应使用GetTickCount。对于游戏逻辑或性能监控而言，其分辨率都太差(64赫兹-令人讨厌的频率，因为它会以典型的监视器刷新率创建拍频)。它是最快的计时函数调用IIRC，但我找不到能弥补其分辨率差的情况。 (编辑:谣言timeBeginPeriod可以提高GetTickCount的分辨率-谣言为FALSE)

对于简单的游戏逻辑计时，RDTSC和QPC都不可靠/古怪，但更适合性能测量。如果您想要独立于CPU频率变化的单元，RDTSC的问题将使使用起来很痛苦，并且通常需要使用asm才能使用它。 QPC通常可以正常工作...但是当它出错时，它可能会出错，并且它以各种各样的方式出错(有时它确实很慢，有时它经常出现小的负增量，有时却很少出现大的负增量) (不是环绕式广告)，有时只是完全精神病等)。 RDTSC几乎总是更快，并且分辨率通常更高。总的来说，我更喜欢将RDTSC用于内部，因为它更快，因此在测量时产生的失真更少。在客户计算机上，这是一个更近的电话-由于Microsoft插入了QPC，因此QPC更容易证明其合理性，并且它的工作频率不会增加复杂性，但是它可以以多种方式固定在客户计算机上，而您永远不会看到它-我认为房子是一个主要缺点。