QueryPerformanceCounter() vs QueryInterruptTime() vs KeQueryInterruptTime() [英] QueryPerformanceCounter() vs QueryInterruptTime() vs KeQueryInterruptTime()

问题描述

我正在编写一个在 Windows 上使用的快速且相当准确的游戏计时器.Microsoft 建议使用 QueryPerformanceCounter() 用于高分辨率计时，它按预期工作，但我正在寻找产生更少执行开销的替代方案.

I am writing a fast and fairly accurate game timer for use on Windows. Microsoft recommends using QueryPerformanceCounter() for high-resolution timing, and it works as expected, but I am looking for alternatives that yield less execution overhead.

我做了一些谷歌搜索，发现提到了 QueryInterruptTime() 及其对应的 QueryInterruptTimePrecise()，它应该更精确，但会产生更大的开销.他们的文档(此处和 此处) 描述他们将系统中断时间计数到最近的系统滴答(或 100ns 单位).QueryInterruptTime() 开始成为一个不错的时机候选者，但关于它的优势和怪癖的文档很少.

I did some Googling and found mention of QueryInterruptTime(), and its counterpart QueryInterruptTimePrecise() which should be more precise but incurs greater overhead. Their documentation (here and here) describes that they get the system interrupt time count to the nearest system tick (or 100ns unit). QueryInterruptTime() is starting to look good as a timing candidate, but there is very little documentation of its advantages and of its quirks.

然后是 KeQueryInterruptTime() 和 KeQueryInterruptTimePrecise()，我不知道他们与他们的非科"兄弟姐妹有何不同.

And then there are KeQueryInterruptTime() and KeQueryInterruptTimePrecise(), and I have no idea how they differ from their "non-Ke" siblings.

谁能描述 QueryInterruptTime() 和 KeQueryInterruptTime()，它们的区别，优缺点，并将它们与更普遍的 QueryPerformanceCounter() 进行比较?

Can anyone describe QueryInterruptTime() and KeQueryInterruptTime(), their differences, pros and cons, and compare them with the more ubiquitous QueryPerformanceCounter() please?

推荐答案

QueryInterruptTime() 和 QueryInterruptTimePrecise() 要求 Windows 10/Server 2016 作为最低版本.

QueryInterruptTime() and QueryInterruptTimePrecise() require Windows 10 / Server 2016 as minimum versions.

您必须阅读获取阅读 QueryPerformanceCounter() 文档时的高分辨率时间戳.这清楚地揭示了 QueryPerformanceCounter() 的优点和缺陷.该函数仅在 HPET 和 PM 计时器平台上显示显着开销，因为它需要在此类平台上进行内核转换.最近的平台确实使用 CPU 时间戳计数器 (TSC) 执行计时和性能计数器业务，开销很小.

You must have read Acquiring high-resolution time stamps while reading the QueryPerformanceCounter() documentation. This clearly discloses the advantages and pitfalls of QueryPerformanceCounter(). The function only shows notable overhead on HPET and PM timer platforms because it requires a kernel transition on such platforms. More recent platforms do perform timekeeping and performance counter business using the CPUs Time Stamp Counter (TSC) with very little overhead.

如果只是精确时间，您还可以查看GetSystemTimePreciseAsFileTime() .Windows 8/Server 2012(仅限桌面)支持此功能.然而，它也在底层使用了性能计数器，因此在开销(HPET/PM 计时器)方面遇到了相同的瓶颈.

If it is just about precise time, you may also look into GetSystemTimePreciseAsFileTime() . This function is supported from Windows 8 / Server 2012 (desktop only). However, it also uses the performance counter under the hood and therefore suffers from the same bottleneck in terms of overhead (HPET/PM timer).

同样适用于函数 QueryInterruptTimePrecise().

函数KeQueryUnbiasedInterruptTime() 可用于内核模式驱动程序，与KeQueryInterruptTimePrecise() 相比，它可以准确地桥接睡眠状态.注意:这里没有内核转换，但您必须在我怀疑的其他地方进行转换.

The function KeQueryUnbiasedInterruptTime() can be used in kernel mode drivers and it can bridge sleep states accurately when compared to KeQueryInterruptTimePrecise(). Note: No kernel transition here but you'd have to do the transition elsewhere I suspect.

不幸的是，没有KeQueryUnbiasedInterruptTimePrecise().

这篇关于QueryPerformanceCounter() vs QueryInterruptTime() vs KeQueryInterruptTime()的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！