On Jan 22, 12:07 am, Terje Mathisen <[email protected]> wrote: > Dave Hart wrote: > > I've also added another fix to the mix, locking both the main thread > > and the high-priority timer thread to the same (2nd) logical processor > > on computers with more than one core or processor. There's already an > > That is a very good idea, and it would even make it feasible to go back > to RDTSC instead of QueryPerformanceCounter(), with the slight caveat > that the TSC frequency can and will change on any machine where > power-reducing frequency changes are allowed.
Reading RDTSC directly is appealing because of the lower overhead but I'd be wary of always using it instead of QPC on x86/x64. If you figure out the clock is stable and RDTSC is a good choice at runtime, wonderful. But with QueryPerformanceCounter you're guaranteed the frequency won't change on the fly, however the HAL and hardware can make that happen. That guarantee was broken for a while when AMD started mucking around with slowing the processor while halacpi.dll was assuming it wouldn't, but I understand the HAL has been updated to either account for the varying RDTSC frequency and compensate or to use a different mechanism underneath QPC. Similarly, I expect more and more PCs will over time have HPET underneath QPC. My long-winded point is there's a lot of work others are doing to keep QueryPerformanceCounter useful and sane, mostly for the benefit of zit- riddled gamers ;) The overhead of the syscall is relatively small and consistent to avoid duplication of that effort. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
