Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

BSXrider

QueryPerformanceCounter: WOW !

This topic is 5980 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''ve been using gettickcount which in my current project would return a difference of 0ms 90% of the time my game looped, and 10ms the other 10%. QueryPerfrmanceCounter is SO much better. It''s frequency seems to be 3579545 times per second ?! - seb

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
Correct me if I''m wrong, but that value depends on your machine.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
It''s a CPU cycle counter, nothing else than the RDTSC command. The resolution is machine dependent. EG. on a 1.4Ghz machine, you''ll roghly get 1.4 billion ticks per second.

Share this post


Link to post
Share on other sites
Use QueryPerformanceFrequency to return the frequency. Take the result from QueryPerformanceCounter divided by what is returned from QueryPerformanceFreqency and you get the time in fractions of a second.

Share this post


Link to post
Share on other sites
So on mine it should be about 800 million and I''m only getting 3 million. Probably an issue with printing type LARGE_INTEGER to the screen.

- seb

Share this post


Link to post
Share on other sites
One thing you should be aware of is that the higher resolution of using QueryPerformanceCounter comes at a cost: the function is considerably slower than many of the alternatives. Check out this paper on NVIDIA''s site, and try the program it comes with.

I''ve found that timeGetTime() works well as a compromise. It''s between GetTickCount and QueryPerformanceCounter performance-wise, and has a resolution of 1 ms, which is good enough for most purposes.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Just note that the AP who said QueryPerformanceCoutner stubs RDSTC is wrong, it does not. THis has been discussed on the DirectX mailing list and confirmed.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Of course it uses RDTSC. It does certainly many more things, that''s why it''s not as performance efficient as rdtsc. But the hardware timestamp counter is the only device in a PC capable of returning this kind of high resolution timing. So, at one moment or the other, QPC will call rdtsc. That''s why there was an MS confirmed issue on the QPC call, that would return bogus results on some very exotic CPU/chipsets combinations. It was a failure of the HW timestamp counter.

Share this post


Link to post
Share on other sites
So QueryPerformanceCounter doesn't work on 486's then? (I find that hard to believe).

QueryPerformanceCounter may use rtdsc in it's implementation, but it's doesn't have to. And it's certainly not the value that it returns.

It takes about 50us to execute (timed with rtdsc ) on my old PC (a 600MHz). Low enough overhead for once a frame, imo.

The problem with using rtdsc directly, is that you also need to _accurately determine the CPU speed. Which is a somewhat tricky thing to do - I always measure some amount of variance...


Edited by - Magmai Kai Holmlor on February 5, 2002 8:49:47 PM

Share this post


Link to post
Share on other sites
quote:

Of course it uses RDTSC. It does certainly many more things, that''s why it''s not as performance efficient as rdtsc. But the hardware timestamp counter is the only device in a PC capable of returning this kind of high resolution timing. So, at one moment or the other, QPC will call rdtsc. That''s why there was an MS confirmed issue on the QPC call, that would return bogus results on some very exotic CPU/chipsets combinations. It was a failure of the HW timestamp counter.



Not sure where you get your info from AP, but...


1) The "known issue" has nothing to do with the failure of the HW timestamp counter. The relevent knowledge base article:
http://support.microsoft.com/directory/article.asp?ID=KB;EN-US;Q274323


2) Executing a RDTSC is one thing QPC() could do, but definately *NOT* what it *always* does.

a. On multiprocessor systems, there is no guarantee that the RDTSC values are synchronised on all CPUs - the OS does not use RDTSC for QPC() on SMP systems where possible.

b. Laptops often use CPUs which *vary* the CPU speed (e.g. Intel SpeedStep). RDTSC counts CPU cycles - when the CPU speed is varying, RDTSC *cannot* be used to accurately measure time. In this case, once again, the OS does not use RDTSC for QPC() where possible.

c. If there is a *hardware* timer of high enough resolution available (not CPU!), QPC() will use that.

d. The implementation differs between the NT kernel and the 9x kernel, and service pack version, but the above has been stated by different people from Microsoft in various online forums.


--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!