RE: [GD-Windows] Performance timing
Brought to you by:
vexxed72
Menu
▾
▴
RE: [GD-Windows] Performance timing
|
From: Jon W. <hp...@mi...> - 2004-02-10 21:41:18
|
GetTickCount() has the same problem as timeGetTime(). RDTSC is MUCH faster. Cheers, / h+ -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of tweety Sent: Tuesday, February 10, 2004 12:43 PM To: gam...@li... Subject: RE: [GD-Windows] Performance timing I preffer gettickcount, by far the fastest way to get the time, besides rdtsc. And even so, they're very comparable and you don't need to do the tick->milisecond transformation. It has a decent enough resolution, too. ---------------------------------- Peace and love, Tweety mi...@sy... - twe...@us... YahooID: tweety_04_01 -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Jon Watte Sent: February 10, 2004 2:21 PM To: gam...@li... Subject: RE: [GD-Windows] Performance timing "Intel specific" as in specific to x86 architecture, specific to Windows, or specific to Intel chips? RDTSC is available on all x86 CPUs, from Intel or elsewhere, from the Pentium generation onwards. I e, you can't be a "level 5 CPU" without RDTSC. That's back when CPUs were running in the 100-200 MHz range, so I think it's safe to assume presence (we do, for sure). QueryPerformanceCounter() typically reads some clock counters in the north bridge (PCI bus clocks? I forget). However, it's a Windows specific call, and does not exist on UNIX (where you can use gettimeofday() and variants, instead) of Macs. Speaking of Macs (and GameCube), the PPC has a time stamp counter very similar to the time stamp counter on x86, so the concept is portable, even though the specific assembly is not. Now, the problems with all three of these methods: timeGetTime() will sometimes "lose" about 20 milliseconds. This happens quite frequently under heavy bus and interrupt load, such as when running a computer game that taxes the IO subsystems and not just the CPU. QueryPerformanceCounter() will sometimes "jump ahead" by a fair bit, on the order of 1-3 seconds. Again, this happens under heavy system load, but is less frequent than the timeGetTime() slip. RDTSC is fine on desktops, but SpeedStep CPUs that vary their CPU speed from moment to moment will screw you over here. Our solution is to spawn busywork to keep the CPU busy, fooling the system into not slowing down the CPU. However, the Pentium-M has Extra Trickiness in this area, which they threaten might make it into future desktop chips (like the Extreme Edition) as well. So, if you want a perfectly stable clock, you have to run all three, and have 'em vote. For micro-benchmarks, we use RDTSC, carefully controlled for cache effects. timeGetTime() and QueryPerformanceCounter() must go out on the (I/O) bus, and thus take like a microsecond each. RDTSC is just a flush and register read; on the order of 30-100 CPU clocks depending on how anal you are about serializing when measuring. VASTLY preferrable :-) Cheers, / h+ -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Carl Bevil Sent: Tuesday, February 10, 2004 10:17 AM To: gam...@li... Subject: [GD-Windows] Performance timing Hello all. I'm wondering what people use these days for timing their code. From what I know, timeGetTime is not so good. In the past I've used QueryPerformanceCounter, and I remember an old Game Developer article about RDTSC timing. But I think at least one of those is Intel-specific. Are there better options I haven't heard about? Thanks, Carl ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=555 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=555 ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=555 |
