Message126274
| Author |
brian.curtin |
| Recipients |
anacrolix, belopolsky, brian.curtin, eric.araujo, glenn, kristjan.jonsson, michael.foord, pitrou, vstinner |
| Date |
2011年01月14日.16:34:35 |
| SpamBayes Score |
3.551786e-05 |
| Marked as misclassified |
No |
| Message-id |
<1295022880.89.0.0780117098464.issue10278@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> In Windows, it should probably use GetTickCount64 if available,
> otherwise GetTickCount with logic to handle wrapping. I think
> QueryPerformanceCounter is problematic as a general-purpose timer:
> depending on the hardware and Windows version, it can be offset
> differently across CPUs, and may not be reliable on some processors. It
> may be fixed in Vista or Win7, I'm not sure; if so it's much higher
> resolution than GTC.
I don't have a ton of experience with this, but by creating a synchronization point based on when the system clock changes, QueryPerformanceCounter can be pretty accurate and as you already stated, and higher resolution than most other solutions. http://msdn.microsoft.com/en-us/magazine/cc163996.aspx is where I got the idea and most of the implementation from. I'm essentially using the code from Figure 2 in a C extension right now to do something similar to threading.Timer in a performance testing tool. |
|