Quote: @Brian: Code paths: Only if you instruct the compiler to do that. And I didn't. Instead, I instructed it to generate code that will run on any Intel *or* AMD system with SSE2 support.
I'll buy that, since you mentioning it knocked down a cobweb in my memory which made me remember a similar discussion we had in the past.
Quote: I have never checked for documentation but these are things I have seen myself in the past. Simple test: Run a profiling program that takes - for example - 10000 snapshots per second. And look at TaskManager. I've seen cases where the profiling program reported that Stereo Tool was using 30% CPU (3000 of the 10000 snapshots resulted in an instruction pointer address inside Stereo Tool), and TaskManager reported 0. I must add that I haven't seen such extreme examples in Windows 7 yet (I saw it in XP).
The thing about me is I worked for a Fortune 500 retailer. We had upwards of 30,000 end-users constantly reporting this, that, or the other as "the system" being broken. As such, we'd spin our wheels trying to test for something that ultimately ended up being something the end-user did incorrectly and / or neglected to mention. From this was born the "Can you document that?" mentality.
As for profiling tools vs. Task Manager, my assumption was you meant VTune. See the following link, which is the very first search entry in Google for "vtune task manager":
http://software.intel.com/en-us/forums/topic/281539
The response was:
Quote:
Are you using Hotspots analysis?
Please consider that CPU usage in Time Stamp also includes CPU consumption of data collector. It means there is overhead caused by the product. Meanwhile your application might include many modules, so CPU consumptions from all modules will be counted...
For lightweight hotspots, ifall active application (system wide) will be monitored and CPU usage is not only for your application.
Regards, Peter
***
In other words, what you saw, you did indeed see, but it may not have represented the same thing as what Task Manager was reporting. Both metrics were "accurate" and / or "correct", but they were looking at different things.
Beyond that though, in your example you mentioned 10000 shots per second, and then said that 3000 were attributed. This indicates that it was a 1 second sampling. Task Manager has four timing settings - 0.5s, 1.0s (default), 2.0s, 4.0s. Ironically, if you change away from the default, at least for XP, you have to edit the registry to get the default back, otherwise your actual choices are 0.5, 2.0, and 4.0. If you take the middle choice ("normal"), you don't have sufficient timer resolution (update frequency).
The bottom line is that I have never, ever seen the discrepancies that you're mentioning. Never. And I've seen quite a lot. Also, I use not only Task Manager, but also Process Explorer.
Process Explorer : http://technet.microsoft.com/en-us/sysi ... 96653.aspx
This utility is by Mark Russinovich, who is considered the foremost expert on the topic with respect to the Windows kernel.
Process Explorer *IS* more accurate than Task Manager, as it factors in things that TM does not.
See here: http://www.techspot.com/community/topic ... er.172232/
... and what is said here (although this is Wiki): http://en.wikipedia.org/wiki/Process_Explorer
Quote:
Process Explorer can be used to track down problems. For example, it provides a means to list or search for named resources that are held by a process or all processes. This can be used to track down what is holding a file open and preventing its use by another program. Or as another example, it can show the command lines used to start a program, allowing otherwise identical processes to be distinguished. Or like Task Manager, it can show a process that is maxing out the CPU, but unlike Task Manager it can show which thread (with the callstack) is using the CPU – information that is not even available under a debugger.
So, in conclusion, I'll buy the default code path discussion, but not about Task Manager. It's too easily explained by the profiling tool measuring different things or that Task Manager's update speed was longer than the sampling, so it showed "0" the whole time.
|
)