Thread: Re: [pgsql-hackers-win32] Help with tuning this query (with
> -----Original Message----- > From: Greg Stark [mailto:gsstark@mit.edu] > Sent: Monday, March 07, 2005 5:15 PM > To: Dave Held > Cc: Greg Stark; John A Meinel; Tom Lane; Magnus Hagander; Ken > Egervari; > pgsql-performance@postgresql.org; pgsql-hackers-win32@postgresql.org > Subject: Re: [pgsql-hackers-win32] [PERFORM] Help with tuning > this query > (with > > "Dave Held" <dave.held@arrayservicesgrp.com> writes: > > > > What would be really neato would be to use the rtdsc (sp?) or > > > equivalent assembly instruction where available. Most > > > processors provide such a thing and it would give much lower > > > overhead and much more accurate answers. > > > > > > The main problem I see with this would be on multi-processor > > > machines. (QueryPerformanceCounter does work properly on > > > multi-processor machines, right?) > > > > I believe QueryPerformanceCounter() already does this. > [...] > Already does what? > > Use rtdsc? Yes. > In which case using it would be a mistake. Since rtdsc doesn't > work across processors. It doesn't always use RDTSC. I can't find anything authoritative on when it does. I would assume that it would use RDTSC when available and something else otherwise. > And using it via QueryPerformanceCounter would be a non-portable > approach to using rtdsc. Much better to devise a portable > approach that works on any architecture where something equivalent > is available. How do you know that QueryPerformanceCounter doesn't use RDTSC where available, and something appropriate otherwise? I don't see how any strategy that explicitly executes RDTSC can be called "portable". > Or already works on multi-processor machines? In which case, uh, ok. According to MSDN it does work on MP systems, and they say that "it doesn't matter which CPU gets called". __ David B. Held Software Engineer/Array Services Group 200 14th Ave. East, Sartell, MN 56377 320.534.3637 320.253.7800 800.752.8129
On Mon, Mar 07, 2005 at 06:11:34PM -0600, Dave Held wrote: >> In which case using it would be a mistake. Since rtdsc doesn't >> work across processors. > It doesn't always use RDTSC. I can't find anything authoritative on > when it does. I would assume that it would use RDTSC when available > and something else otherwise. RDTSC is a bad source of information for this kind of thing, as the CPU frequency might vary. Check your QueryPerformanceFrequency() -- most likely it will not match your clock speed. I haven't tested on a lot of machines, but I've never seen QueryPerformanceFrequency() ever match the clock speed, which it most probably would if it was using RDTSC. (I've been told it uses some other kind of timer available on most motherboards, but I don't know the details.) /* Steinar */ -- Homepage: http://www.sesse.net/
"Steinar H. Gunderson" <sgunderson@bigfoot.com> writes:
> RDTSC is a bad source of information for this kind of thing, as the CPU
> frequency might vary.
One thought that was bothering me was that if the CPU goes idle while
waiting for disk I/O, its clock might stop or slow down dramatically.
If we believed such a counter for EXPLAIN, we'd severely understate
the cost of disk I/O.
I dunno if that is the case on any Windows hardware or not, but none
of this thread is making me feel confident that we know what
QueryPerformanceCounter does measure.
regards, tom lane
On Mon, Mar 07, 2005 at 09:02:38PM -0500, Tom Lane wrote: > One thought that was bothering me was that if the CPU goes idle while > waiting for disk I/O, its clock might stop or slow down dramatically. > If we believed such a counter for EXPLAIN, we'd severely understate > the cost of disk I/O. > > I dunno if that is the case on any Windows hardware or not, but none > of this thread is making me feel confident that we know what > QueryPerformanceCounter does measure. I believe the counter is actually good in such a situation -- I'm not a Win32 guru, but I believe it is by far the best timer for measuring, well, performance of a process like this. After all, it's what it was designed to be :-) OBTW, I think I can name something like 15 or 20 different function calls to measure time in the Win32 API (all of them in use); it really is a giant mess. /* Steinar */ -- Homepage: http://www.sesse.net/
From the Linux Kernel (make menuconfig) there seem to be two new reliable
sources for timing information. Note the remark about "Time Stamp Counter"
below. Question is, which one of these (or others) are your API functions
using ? I have absolutely no idea !
CONFIG_HPET_TIMER:
This enables the use of the HPET for the kernel's internal timer.
HPET is the next generation timer replacing legacy 8254s.
You can safely choose Y here. However, HPET will only be
activated if the platform and the BIOS support this feature.
Otherwise the 8254 will be used for timing services.
Choose N to continue using the legacy 8254 timer.
Symbol: HPET_TIMER [=y]
Prompt: HPET Timer Support
Defined at arch/i386/Kconfig:440
Location:
-> Processor type and features
CONFIG_X86_PM_TIMER:
The Power Management Timer is available on all
ACPI-capable, in most cases even if
ACPI is unusable or blacklisted.
This timing source is not affected by powermanagement
features like aggressive processor
idling, throttling, frequency and/or
voltage scaling, unlike the commonly used Time Stamp
Counter (TSC) timing source.
So, if you see messages like 'Losing too many ticks!' in
the kernel logs, and/or you are using
this on a notebook which does not
yet have an HPET, you should say "Y" here.
Symbol: X86_PM_TIMER
[=y]
Prompt: Power Management Timer
Support
Defined at
drivers/acpi/Kconfig:319
Depends on: !X86_VOYAGER && !X86_VISWS && !IA64_HP_SIM && (IA64 || X86) &&
X86 && ACPI && ACPI_
Location:
-> Power management options (ACPI,
APM) -> ACPI
(Advanced Configuration and Power Interface)
Support -> ACPI Support (ACPI [=y])
On Tue, 08 Mar 2005 03:06:24 +0100, Steinar H. Gunderson
<sgunderson@bigfoot.com> wrote:
> On Mon, Mar 07, 2005 at 09:02:38PM -0500, Tom Lane wrote:
>> One thought that was bothering me was that if the CPU goes idle while
>> waiting for disk I/O, its clock might stop or slow down dramatically.
>> If we believed such a counter for EXPLAIN, we'd severely understate
>> the cost of disk I/O.
>>
>> I dunno if that is the case on any Windows hardware or not, but none
>> of this thread is making me feel confident that we know what
>> QueryPerformanceCounter does measure.
>
> I believe the counter is actually good in such a situation -- I'm not a
> Win32
> guru, but I believe it is by far the best timer for measuring, well,
> performance of a process like this. After all, it's what it was designed
> to
> be :-)
>
> OBTW, I think I can name something like 15 or 20 different function
> calls to
> measure time in the Win32 API (all of them in use); it really is a giant
> mess.
>
> /* Steinar */