Thread: [GD-Windows] Performance timing
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows
|
From: Carl B. <car...@ya...> - 2004-02-10 18:16:49
|
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 |
|
From: Jon W. <hp...@mi...> - 2004-02-10 19:23:48
|
"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 |
|
From: tweety <mi...@sy...> - 2004-02-10 20:42:48
|
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 |
|
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 |
|
From: Carl B. <car...@ya...> - 2004-02-11 00:01:02
|
Hi Jon, > "Intel specific" as in specific to x86 architecture, specific to Windows, or > specific to Intel chips? Specific to Intel chips. For some reason I had it in my head that some of these methods only worked on "genuine Intel" chips, but not on, say, AMD chips. [...] > 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 :-) Wow, thanks for this information. More than I expected, and very helpful! Carl |
|
From: Simon O'C. <si...@sc...> - 2004-02-11 00:45:29
|
Hi Carl, Have a search around nVidia's developer website (http://developer.nvidia.com), IIRC they did presentation surveying each of the major timing methods with regard to using them to profile code and the advantages and disadvantages plus latencies of each. If you decide to use any of the Windows OS timing functions, be sure to search the KnowledgeBase on MSDN for the function names. There are a number of known issues (many Jon has covered in his post already) detailed in the KB; including which OSes and hardware the issues show up on and any known work-arounds. IIRC QueryPerformanceCounter() will perform its timing in different ways depending on the OS version, whether SMP is in use, whether speed stepping is present, what motherboard hardware is present etc. ISTR a post from one of the MS guys on DirectXDev in about 1999 mentioning this (should still be in the archives for that list). Cheers, Simon O'Connor Programmer @ Acclaim & Microsoft DirectX MVP > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On > Behalf Of Carl Bevil > Sent: 11 February 2004 00:01 > To: Jon Watte > Subject: Re[2]: [GD-Windows] Performance timing > > Hi Jon, > > > "Intel specific" as in specific to x86 architecture, specific to > > Windows, or specific to Intel chips? > > Specific to Intel chips. For some reason I had it in my head > that some of these methods only worked on "genuine Intel" > chips, but not on, say, AMD chips. > > [...] > > 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 :-) > > Wow, thanks for this information. More than I expected, and > very helpful! > > 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 > > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004 > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.572 / Virus Database: 362 - Release Date: 27/01/2004 |
|
From: Brian H. <ho...@py...> - 2004-02-11 00:58:20
|
Ya know, the whole damn industry would benefit if someone would actually do a good, solid comprehensive write up with a code example of "take three votes" method. Just sayin'. =3D) Brian |
|
From: <cas...@ya...> - 2004-02-13 01:05:33
|
Brian Hook wrote: > Ya know, the whole damn industry would benefit if someone would > actually do a good, solid comprehensive write up with a code example > of "take three votes" method. Just sayin'. =) Agreed. There's a project that provides a high resolution timer for the linux kernel: (yes, I know this is a windows mailing list) http://sourceforge.net/projects/high-res-timers/ It provides an implementation of the POSIX timers using a combination of several methods: the old 8254, the internal Pentium TSC and the ACPI timers. Currently there are patches for 2.4 and 2.6, but it's not on the main trunk jet. However, the problem is not to have a good system timer, but to deal with old systems, that still have a buggy timers. As you say, a code example of the voting method would really help. -- Ignacio Castaño cas...@ya... |
|
From: Carl B. <car...@ya...> - 2004-02-11 01:27:07
|
Did that, and they have a nice utility that performs some timing tests on your machine and spits out a report (it's at http://developer.nvidia.com/object/timer_function_performance.html). The report had interesting results: ----- QueryPerformanceFrequency() freq = 0 2593560000 method 0: QueryPerfCntr..() 10000 times tot: 0 6720740 avg: 672.074000 avg time: 2.59132e-007 method 1: GetTickCount() 10000 times tot: 0 260708 avg: 26.070800 avg time: 1.00521e-008 method 2: TimeGetTime() 10000 times tot: 0 1420712 avg: 142.071200 avg time: 5.47785e-008 method 3: Pentium internal high-freq cntr() 10000 times tot: 0 840856 avg: 84.085600 avg time: 3.24209e-008 ----- I've left out the data for less than 10,000 iterations for sake of length; the averages were similar for these cases (and I ran the test a couple times with similar results). It looks like GetTickCount is the fastest, at least for this test setup on my machine. Am I reading the results wrong? I would have expected RDTSC to be the fastest. What could this mean? Is this because of the cache effects that Jon mentioned? Just curious. :-) Tbanks! Carl ------------------------------------------ Tuesday, February 10, 2004, 4:44:01 PM, you wrote: > Hi Carl, > Have a search around nVidia's developer website > (http://developer.nvidia.com), IIRC they did presentation surveying each of > the major timing methods with regard to using them to profile code and the > advantages and disadvantages plus latencies of each. |
|
From: tweety <mi...@sy...> - 2004-02-11 09:00:04
|
Same here; this was what I was talking about. Besides, rdtsc and queryperformancetimer has some very nasty sincronization problems with multiple processors (they give the time slightly different wether the code is run on different processors). Good old GetTickCount does its job :) ---------------------------------- Peace and love, Tweety mi...@sy... - twe...@us... YahooID: tweety_04_01 -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Carl Bevil Sent: February 10, 2004 8:27 PM To: Simon O'Connor Subject: Re[4]: [GD-Windows] Performance timing Did that, and they have a nice utility that performs some timing tests on your machine and spits out a report (it's at http://developer.nvidia.com/object/timer_function_performance.html). The report had interesting results: ----- QueryPerformanceFrequency() freq = 0 2593560000 method 0: QueryPerfCntr..() 10000 times tot: 0 6720740 avg: 672.074000 avg time: 2.59132e-007 method 1: GetTickCount() 10000 times tot: 0 260708 avg: 26.070800 avg time: 1.00521e-008 method 2: TimeGetTime() 10000 times tot: 0 1420712 avg: 142.071200 avg time: 5.47785e-008 method 3: Pentium internal high-freq cntr() 10000 times tot: 0 840856 avg: 84.085600 avg time: 3.24209e-008 ----- I've left out the data for less than 10,000 iterations for sake of length; the averages were similar for these cases (and I ran the test a couple times with similar results). It looks like GetTickCount is the fastest, at least for this test setup on my machine. Am I reading the results wrong? I would have expected RDTSC to be the fastest. What could this mean? Is this because of the cache effects that Jon mentioned? Just curious. :-) Tbanks! Carl ------------------------------------------ Tuesday, February 10, 2004, 4:44:01 PM, you wrote: > Hi Carl, > Have a search around nVidia's developer website > (http://developer.nvidia.com), IIRC they did presentation surveying > each of the major timing methods with regard to using them to profile > code and the advantages and disadvantages plus latencies of each. ------------------------------------------------------- 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 |
|
From: chaac <ch...@ni...> - 2004-02-11 10:40:24
|
tweety wrote: > Same here; this was what I was talking about. > Besides, rdtsc and queryperformancetimer has some very nasty sincronization > problems with multiple processors (they give the time slightly different > wether the code is run on different processors). > Good old GetTickCount does its job :) Hi, But then again, if I remember correcly, GetTickCount goes in steps of 32ms. If you need more accuracy, you are out of the game here. And if you are just profiling on your development machine or at machine you can reach or otherwise know some details about it. You can quite easily use other measurement methods also. In some cases how fast to get time is not the issue, but accuracy of delta time is. Thanks, Vesa Jääskeläinen |
|
From: tweety <mi...@sy...> - 2004-02-11 19:30:26
|
Disagree again :)
I wrote the following program:
-----------------------------------
#include "stdafx.h"
#include <windows.h>
int _tmain(int argc, _TCHAR* argv[])
{
DWORD currenttick=3DGetTickCount(), oldtick=3Dcurrenttick,
starttick=3Dcurrenttick;
while(currenttick - starttick<=3D10000)
{
currenttick=3DGetTickCount();
if(oldtick!=3Dcurrenttick)
{
printf("%10d\n", currenttick);
oldtick=3Dcurrenttick;
}
}
return 0;
}
-----------------------------------
And part of its output is:
-----------------------------------
70250890
70250906
70250921
70250937
70250953
70250968
70250984
70251000
70251015
70251031
70251046
70251062
70251078
70251093
70251109
70251125
-----------------------------------
As you can see, the delta is between 15-16ms. More than enough to count =
time
between 60hz frames...
----------------------------------
Peace and love,
Tweety
mi...@sy... - twe...@us...
YahooID: tweety_04_01
-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of =
chaac
Sent: February 11, 2004 5:40 AM
To: gam...@li...
Subject: Re: [GD-Windows] Performance timing
tweety wrote:
> Same here; this was what I was talking about.
> Besides, rdtsc and queryperformancetimer has some very nasty=20
> sincronization problems with multiple processors (they give the time=20
> slightly different wether the code is run on different processors).
> Good old GetTickCount does its job :)
Hi,
But then again, if I remember correcly, GetTickCount goes in steps of =
32ms.
If you need more accuracy, you are out of the game here.
And if you are just profiling on your development machine or at machine =
you
can reach or otherwise know some details about it. You can quite easily =
use
other measurement methods also.
In some cases how fast to get time is not the issue, but accuracy of =
delta
time is.
Thanks,
Vesa J=E4=E4skel=E4inen
-------------------------------------------------------
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=3D555
|
|
From: Jon W. <hp...@mi...> - 2004-02-11 21:52:34
|
> As you can see, the delta is between 15-16ms. More than enough to count time > between 60hz frames... How many frames are you talking about? A single 60 Hz frame is 16 milliseconds. That's it. If you take longer, it's not 60 Hz anymore. I think we already agreed that, for timing over 100 or even 1000 frames, pretty much anything works (although you'll still be on the order of 1% off on GetTickCount()). For timing over 10 frames, being off by a whole frame's worth is pretty bad. Cheers, / h+ |
|
From: Martin S. <ms...@he...> - 2004-02-12 02:17:36
|
Just noticed that there is an article in Windows Developer Nwetowkr magazine that discusses the different timer mechanisms available under windows. It gives call costs and some other analysis. Maybe interesting. @ http://www.windevnet.com/wdn/issues/2003/0305/pdf/wdn200305.zip Martin > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On Behalf Of Jon > Watte > Sent: Thursday, 12 February 2004 7:49 AM > To: gam...@li... > Subject: RE: [GD-Windows] Performance timing > > > > As you can see, the delta is between 15-16ms. More than enough to count > time > > between 60hz frames... > > > How many frames are you talking about? > > A single 60 Hz frame is 16 milliseconds. That's it. If you take longer, > it's > not 60 Hz anymore. > > I think we already agreed that, for timing over 100 or even 1000 frames, > pretty much anything works (although you'll still be on the order of 1% > off > on GetTickCount()). > > For timing over 10 frames, being off by a whole frame's worth is pretty > bad. > > Cheers, > > / h+ > > > > ------------------------------------------------------- > SF.Net is sponsored by: Speed Start Your Linux Apps Now. > Build and deploy apps & Web services for Linux with > a free DVD software kit from IBM. Click Now! > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 |
|
From: tweety <mi...@sy...> - 2004-02-11 19:31:26
|
Oh... Forgot to mention my specs: amd xp 2500+, windows xp professional = sp1 ---------------------------------- Peace and love, Tweety mi...@sy... - twe...@us... YahooID: tweety_04_01 -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of = chaac Sent: February 11, 2004 5:40 AM To: gam...@li... Subject: Re: [GD-Windows] Performance timing tweety wrote: > Same here; this was what I was talking about. > Besides, rdtsc and queryperformancetimer has some very nasty=20 > sincronization problems with multiple processors (they give the time=20 > slightly different wether the code is run on different processors). > Good old GetTickCount does its job :) Hi, But then again, if I remember correcly, GetTickCount goes in steps of = 32ms. If you need more accuracy, you are out of the game here. And if you are just profiling on your development machine or at machine = you can reach or otherwise know some details about it. You can quite easily = use other measurement methods also. In some cases how fast to get time is not the issue, but accuracy of = delta time is. Thanks, Vesa J=E4=E4skel=E4inen ------------------------------------------------------- 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=3D555 |
|
From: Jon W. <hp...@mi...> - 2004-02-11 17:53:06
|
> Besides, rdtsc and queryperformancetimer has some very nasty sincronization > problems with multiple processors (they give the time slightly different > wether the code is run on different processors). QueryPerformanceCounter() typically uses the chip set, rather than CPU, counters, to avoid this problem. It is up to the OS to synchronize RDTSC on boot-up. If it doesn't, the OS is broken. Luckily, I've never used an OS where it was broken. (We had all kinds of fun getting them in sync in the BeOS kernel, but we did it.) Cheers, / h+ |
|
From: Jon W. <hp...@mi...> - 2004-02-11 17:53:07
|
That's interesting! As others have said: the accuracy of GetTickCount() varies highly depending on your system in general, as it polls some variable that gets updated once in a while; that's why it's the fastest. For a FPS counter, it's probably accurate enough. When you run micro-benchmarks like this, 10,000 calls might not be enough. Get interrupted once by a task switch, or just network packet/mouse movement, and your measurement is off. That's why I prefer measuring the BEST sample out of many samples. That, for RDTSC, is on the order of 40 cycles, if you don't care about temporal serialization (which you typically don't). Hard to say more without more details about the benchmark, though. (I've been burned by benchmarks measuring something other than I thought they did SOOO many times it's not even funny anymore). Cheers, / h+ -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Carl Bevil Sent: Tuesday, February 10, 2004 5:27 PM To: Simon O'Connor Subject: Re[4]: [GD-Windows] Performance timing Did that, and they have a nice utility that performs some timing tests on your machine and spits out a report (it's at http://developer.nvidia.com/object/timer_function_performance.html). The report had interesting results: ----- QueryPerformanceFrequency() freq = 0 2593560000 method 0: QueryPerfCntr..() 10000 times tot: 0 6720740 avg: 672.074000 avg time: 2.59132e-007 method 1: GetTickCount() 10000 times tot: 0 260708 avg: 26.070800 avg time: 1.00521e-008 method 2: TimeGetTime() 10000 times tot: 0 1420712 avg: 142.071200 avg time: 5.47785e-008 method 3: Pentium internal high-freq cntr() 10000 times tot: 0 840856 avg: 84.085600 avg time: 3.24209e-008 ----- I've left out the data for less than 10,000 iterations for sake of length; the averages were similar for these cases (and I ran the test a couple times with similar results). It looks like GetTickCount is the fastest, at least for this test setup on my machine. Am I reading the results wrong? I would have expected RDTSC to be the fastest. What could this mean? Is this because of the cache effects that Jon mentioned? Just curious. :-) Tbanks! Carl ------------------------------------------ Tuesday, February 10, 2004, 4:44:01 PM, you wrote: > Hi Carl, > Have a search around nVidia's developer website > (http://developer.nvidia.com), IIRC they did presentation surveying each of > the major timing methods with regard to using them to profile code and the > advantages and disadvantages plus latencies of each. ------------------------------------------------------- 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X