Is the HPET directly accessible in Windows?

Question

I would like to use the High Performance Event Timer (HPET) for an profiling tool to take very high precision measurements, quickly. timeGetTime does not provide sufficient resolution at 1ms, and QueryPerformanceCounter is much slower per read than I'd like. I came across the HPET while researching the problem, but I can't see any samples of how to actually get at it.

So can I use it directly (assembly is fine), or do I have to rely on the multimedia/high performance timing tools already built into the Win32 API?

Draughts

I would love to use it too, as I guess I suffer the same problem in my profiler. – Overspread

This seems related: msdn.microsoft.com/en-us/magazine/cc163996.aspx – Vet

As a further update: RDTSC and QueryPerformanceCounter are not safe to use when the system has a non-constant base frequency (overclocking within the system). Windows fails to adjust the QPC frequency in those cases which leads to skewed timings. In those cases, HPET and ACPI remain the only alternatives for a reliable timer. Therefore, this question remains open and unanswered. – Whistling

@Whistling incorrect. this is only applicable to older cpus and systems. try this code: randomascii.wordpress.com/2011/07/29/… try it yourself on your system before stating false statements!!! – Flemming

The article you linked is incomplete. It only covers multiplier-based clock scaling. It does not cover base clock scaling. Anyone who has experience with overclocking will know that base clock and multiplier are separate. Changing the base clock while the computer is already booted up (via an overclocking utility such as Intel XTU) will affect the rdtsc frequency since rdtsc is derived from the base clock. Furthermore, the OS doesn't know to re-calibrate its timers when the base clock is changed this way. – Whistling

For more information: hwbot.org/news/… I write benchmarks for competitive overclocking, so I have actually personally tested it myself. Not only can I confirm the findings in the HWBOT article, but I can confirm that rdtsc drift happens on all OS's. Furthermore QPC drift happens on Windows 8 or later when not using a platform clock like HPET or ACPI. – Whistling

Microsoft clearly recommends to use QPC. See this blogs.msdn.microsoft.com/chuckw/2014/12/03/… and this 'Acquiring high-resolution time stamps' msdn.microsoft.com/en-us/library/windows/desktop/dn553408.aspx – Ginn

@SimonMourier They recommend it because even there's no better option other than to directly access the HPET or another hardware clock - which doesn't seem possible in user mode and require a kernel mode driver. Systems with variable base clock are rare enough that Microsoft either doesn't know about their existence, or they simply don't care. – Whistling

@Whistling - they certainly have their reasons, but the/their answer is basically the same "Is the HPET directly accessible in Windows?" -> No – Ginn

The HPET is virtual, it is a component that the system builder must provide. He can pick anything he wants, as long as it meets the HPET requirements. The HAL interfaces to it, normally done by the chipset driver. It does have a well-known userland api to access it, drumroll, it is QPF. The kernel-mode context switch is inevitable overhead. FUD about RDTSC is heavily outdated, at Win8 it became formally supported by QueryThreadCycleTime(). – Thermomagnetic

Answer 1

I found this info while digging around, and it seems it can be the most cost effective way. I will try it out when I get the guts to dig into assembly. :)

UPDATE

I tested this with my profiler. although a bit faster, it seems I still have tonnes of other overhead :( (I did not bother with timing as I it did not seem to be enough benefit)

Overspread

No! Don't use RDTSC, it will do strange things on multicore machines. Each core having it's own counter can give effects like functions taking negative time ect. The Timestamp counters aren't always in sync! Been there, done that. – Communalism

And say you keep track of the thread? How can that affect the difference? – Overspread

Keeping track of the thread will just tell you that there might be a problem, not if there is a problem or how to fix it. To use RDTSC safely you must pin the thread to a specific core. There is no way to safely compute the RDTSC difference across cores from userspace. – Jegger

In case someone stumbles on this, modern procs with the TSC Invariant bit of CPUID set can safely use RDTSC without affinity and there is no risk of Speed Step or sleep states or anything messing with the TSC rate. – Cade

@Cade ...and since CPUID can be read in Windows with __cpuid, this can actually be checked. – Collotype

Answer 2

I am also interested in using the HPET, but as a timer. The way I understand it, QueryPerformanceCounter and QueryPerformanceFrequency are actually accessing the counter and clock for the HPET, and this works under Windows XP (see, for example, http://www.geisswerks.com/ryan/FAQS/timing.html).

So as far as timing code, I think by using QueryPerformanceCounter you are in fact getting access to the counter that form the base of HPET, and this is all present in the chipset (rather than the processor).

Rhizopod

As I understand, XP does NOT support HPET, so QueryPerformanceCounter is actually using RDTSC. – Actinomycete

See en.wikipedia.org/wiki/High_Precision_Event_Timer#cite_note-7 (note on XP SP3 in "Use and compatibility") for full explanation. In brief, XP uses a "best effort" HPET emulation with software and various hardware. – Collotype