Re: QueryPerformanceCounter question
- From: "DC" <***@***.com>
- Date: Tue, 25 Jul 2006 09:39:00 +0100
Thanks Daniel,
If you're keen to make a framework, you'll probably get the most accurate
and stable results by using QPC with thread priority boosted all the way
up and thread affinity set to a single CPU. Of course, this is only
practial in a test environment where you're assessing the performance of
individual functions or other compute-bound workloads one against another.
You'd never want to attempt to measure the performance of a real-world
application using such techniques, and forget about measuring the
performance of multiple threads simultaneously using this technique (well,
maybe 1 thread per CPU, but even that's probably pushing it).
You can use GetThreadTimes, but the resolution is very low. You're likely
to see a lot of aliasing in your results unless your threads remain
compute bound for long periods of time, or you gather data over a long
period of time (several minutes at least - maybe more).
Thanks pretty much the conclusion I came to last night night.
"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@xxxxxxxxxxxxxxx>
wrote in message news:OtsJwQ5rGHA.4856@xxxxxxxxxxxxxxxxxxxxxxx
DC wrote:
Ah. I still haven't had a chance to look at the code.
In response to the issues you raised, I guess I can use a thread
affinity mask to force the scheduler into keeping me on 1 cpu?
The thing is, I still don't have much more to go on as to what the
best approach to profiling is. Bear in mind, I wanted to be as
accurate as possible and if a thread context switch occurs between
the 2 QPC calls then my result will be affected. Worse, when I run
the same (of different) test again a context switch may not happen.
This is why I was looking at GetThreadTimes.
What's the opinions on the this?
The best way to do profiling is to use a profiler.
The fact is, that running under a preemptive OS like windows, there's
simply no way to measure performance independently from other activity on
the system. The closest that you can practially get for most real-world
apps is to use a sampling profiler to gather statistical profile data for
your application while running a test workload over a relatively long
period of time. The sampling profiler removes a great deal of the
influence of the rest of the system since only samples where the CPU was
actually executing your process/threads are counted.
If you're keen to make a framework, you'll probably get the most accurate
and stable results by using QPC with thread priority boosted all the way
up and thread affinity set to a single CPU. Of course, this is only
practial in a test environment where you're assessing the performance of
individual functions or other compute-bound workloads one against another.
You'd never want to attempt to measure the performance of a real-world
application using such techniques, and forget about measuring the
performance of multiple threads simultaneously using this technique (well,
maybe 1 thread per CPU, but even that's probably pushing it).
You can use GetThreadTimes, but the resolution is very low. You're likely
to see a lot of aliasing in your results unless your threads remain
compute bound for long periods of time, or you gather data over a long
period of time (several minutes at least - maybe more).
-cd
.
- References:
- QueryPerformanceCounter question
- From: DC
- Re: QueryPerformanceCounter question
- From: Hector Santos
- Re: QueryPerformanceCounter question
- From: DC
- Re: QueryPerformanceCounter question
- From: Hector Santos
- Re: QueryPerformanceCounter question
- From: Carl Daniel [VC++ MVP]
- Re: QueryPerformanceCounter question
- From: DC
- Re: QueryPerformanceCounter question
- From: Carl Daniel [VC++ MVP]
- QueryPerformanceCounter question
- Prev by Date: Re: What does Zw stand for?
- Next by Date: Re: Named Pipes Restriction
- Previous by thread: Re: QueryPerformanceCounter question
- Next by thread: Re: QueryPerformanceCounter question
- Index(es):
Relevant Pages
|