windows 当 QueryPerformanceCounter 被调用时会发生什么？

What happens when QueryPerformanceCounter is called?

提问by Matt Price

I'm looking into the exact implications of using QueryPerformanceCounter in our system and am trying to understand it's impact on the application. I can see from running it on my 4-core single cpu machine that it takes around 230ns to run. When I run it on a 24-core 4 cpu xeon it takes around 1.4ms to run. More interestingly on my machine when running it in multiple threads they don't impact each other. But on the multi-cpu machine the threads cause some sort of interaction that causes them to block each other. I'm wondering if there is some shared resource on the bus that they all query? What exactly happens when I call QueryPerformanceCounter and what does it really measure?

我正在研究在我们的系统中使用 QueryPerformanceCounter 的确切含义，并试图了解它对应用程序的影响。从我的 4 核单 CPU 机器上运行它可以看出，它需要大约 230ns 才能运行。当我在 24 核 4 cpu xeon 上运行它时，它需要大约 1.4 毫秒才能运行。更有趣的是，在我的机器上以多个线程运行时，它们不会相互影响。但是在多 CPU 机器上，线程会引起某种交互，导致它们相互阻塞。我想知道总线上是否有一些他们都查询的共享资源？当我调用 QueryPerformanceCounter 时到底发生了什么，它真正衡量的是什么？

采纳答案by Ron Warholic

Windows QueryPerformanceCounter() has logic to determine the number of processors and invoke syncronization logic if necessary. It attempts to use the TSC register but for multiprocessor systems this register is not guaranteed to be syncronized between processors (and more importantly can vary greatly due to intelligent downclocking and sleep states).

Windows QueryPerformanceCounter() 具有确定处理器数量并在必要时调用同步逻辑的逻辑。它尝试使用 TSC 寄存器，但对于多处理器系统，不能保证该寄存器在处理器之间同步（更重要的是，由于智能降频和睡眠状态，可能会有很大差异）。

MSDN says that it doesn't matter which processor this is called on so you may be seeing extra syncronization code for such a situation cause overhead. Also remember that it can invoke a bus transfer so you may be seeing bus contention delays.

MSDN 说调用哪个处理器无关紧要，因此您可能会看到额外的同步代码导致这种情况的开销。还请记住，它可以调用总线传输，因此您可能会看到总线争用延迟。

Try using SetThreadAffinityMask() if possible to bind it to a specific processor. Otherwise you might just have to live with the delay or you could try a different timer (for example take a look at http://en.wikipedia.org/wiki/High_Precision_Event_Timer).

如果可能，请尝试使用 SetThreadAffinityMask() 将其绑定到特定处理器。否则，您可能只需要忍受延迟，或者您可以尝试不同的计时器（例如查看http://en.wikipedia.org/wiki/High_Precision_Event_Timer）。

回答by istudy0

I know that this thread is a bit old but I would like to add more info. First, I do agree that QueryPerformanceCounter can take more time on certain machines, but I am not sure if Ron's answer is the reason for that all the time. While I was doing some research on this issue, I found a various web pages that talks about how QueryPerformanceCounter is implemented. For instance, Precision is not the same as accuracytells me that Windows, HAL to be more specific would use different timing device to obtain the value. This means that if windows get to use slower timing device such as PIT, it will take more time to obtain the time value. Obviously, using PIT might require PCI transaction so that would be one reason.

我知道这个线程有点旧，但我想添加更多信息。首先，我确实同意 QueryPerformanceCounter 在某些机器上可能需要更多时间，但我不确定 Ron 的回答是否一直是造成这种情况的原因。当我对这个问题做一些研究时，我发现了一个关于如何实现 QueryPerformanceCounter 的各种网页。例如，Precision 和accuracy 不一样，告诉我Windows，HAL 更具体地说会使用不同的计时设备来获取值。这意味着如果 Windows 使用较慢的计时设备，例如 PIT，则需要更多时间来获取时间值。显然，使用 PIT 可能需要 PCI 事务，因此这将是一个原因。

I also found another article: How It Works: Timer Outputs in SQL Server 2008 R2 - Invariant TSC giving similar description. In fact, this article tells how SQLServer would time the transaction in the best way.

我还发现了另一篇文章：How It Works: Timer Outputs in SQL Server 2008 R2 - Invariant TSC 给出了类似的描述。事实上，本文讲述了 SQLServer 如何以最佳方式为事务计时。

Then, I found more information on VMware site because I had to deal with customers who are using VMs and I found that there are other issues with time measurement with VMs. For those who are interested, please refer to VMware paper - Timekeeping in VMware Virtual Machines In this paper, it also talks about how some versions of windows would synchronize each TSCs. Thus, it would be safe to use QueryPerformanceCounter() in certain situations and I think that we should try something like what How It Works: Timer Outputs in SQL Server 2008 R2 suggested to find what might happen when we call QueryPerformanceCounter()

然后，我在 VMware 站点上找到了更多信息，因为我必须与使用 VM 的客户打交道，而且我发现使用 VM 进行时间测量还有其他问题。有兴趣的可以参考VMware论文-VMware Virtual Machines中的Timekeeping 在这篇论文中，还谈到了一些版本的windows如何同步每个TSC。因此，在某些情况下使用 QueryPerformanceCounter() 是安全的，我认为我们应该尝试类似 How It Works: Timer Outputs in SQL Server 2008 R2 的建议，以找出调用 QueryPerformanceCounter() 时可能发生的情况

回答by Aaron

I was under the impression that on x86 QueryPerformanceCounter() just called rdtsc under the covers. I'm suprised that it has any slowdown on multi-core machines (I've never noticed it on my 4-core cpu).

我的印象是在 x86 上 QueryPerformanceCounter() 只是在幕后调用了 rdtsc。我很惊讶它在多核机器上有任何减速（我从未在我的 4 核 CPU 上注意到它）。

回答by mkgrunder

It's been a long time since I used this much, but if memory serves there isn't one implementation of this function, as the guts are provided by the various hardware manufacturers.

我已经很久没有使用这么多了，但如果没有记错的话，这个功能没有一个实现，因为各种硬件制造商都提供了胆量。

Here is a small article from MSDN: http://msdn.microsoft.com/ja-jp/library/cc399059.aspx

这是 MSDN 上的一篇小文章：http: //msdn.microsoft.com/ja-jp/library/cc399059.aspx

Also, if you're querying performance across multiple CPUs (as opposed to multiple cores on one CPU), it's going to have to communicate across the bus, which is both slower and could be where you are seeing some blocking.

此外，如果您要跨多个 CPU（而不是一个 CPU 上的多个内核）查询性能，则必须通过总线进行通信，这既慢又可能是您看到一些阻塞的地方。

However, like I said before it's been quite a while.

然而，就像我之前说的，已经有一段时间了。

Mike

麦克风