Author: Robert Hyatt
Date: 06:48:16 01/26/00
Go up one level in this thread
On January 26, 2000 at 02:54:26, Jeremiah Penery wrote: >On January 25, 2000 at 23:42:41, Robert Hyatt wrote: > >>On January 25, 2000 at 19:21:31, Peter Fendrich wrote: >> >>>On January 25, 2000 at 19:02:24, Dann Corbit wrote: >>> >>>>On January 25, 2000 at 18:56:37, Peter Fendrich wrote: >>>> >>>>>I tried to use the clock() function (in NT4) and it didn't behave as I expected >>>>>it to. >>>>>It is said to "Return elapsed CPU time for current process". >>>>>I hoped to be able to run performance tests with my chess program in the >>>>>background while doing other things in the foreground and yet get the same >>>>>results. >>>>>The clock() is definitely affected by other processes so I get very varied >>>>>results depending on what I'm doing in the foreground. >>>>> >>>>>How come? >>>> >>>>The cost of the context switches. The context switches in and out of your >>>>threads will still be part of the time used by your process. >>> >>>ok, maybe I have a simplified view of processes in NT but when the clock() >>>function is said to "Calculate the processor time used by the calling process" >>>my interpretation is that this is the effective time used by the process itself. >>>Other processes time shouldn't be counted in. >> >>partially correct. It counts _only_ your clock ticks, but unfortunately your >>clock ticks can be increased by what other processes do. For example a context- >>switch blows out L1/L2 cache. It takes you a while to re-load cache when your >>process gets control again, and this 'extra' time gets charged to you. The TLB >>in the memory management hardware also gets flushed. And this makes the first >>memory references take an abnormally long time. And then there is the time of >>the context switches themselves... >> >>And if another process uses enough memory to cause you to page a bit, then >>you get charged for the paging overhead for your page reads/writes. And if you >>(when running by yourself) use a large chunk of memory for page cache to avoid >>some I/O, when running with another process you don't get as much memory for >>this cache and you can do extra I/O. And you get charged for the cpu time to >>initiate this extra I/O. > >I'm not sure how the NT Task Manager does it, but it seems to do a really good >job of calculating the current CPU usage for each process and the elapsed CPU >time for each process. During disk access (memory paging, or EGTB probes), the >CPU usage goes down on this. The thing never shows 100% of the CPU being used, >either - I think because of context switches. I think there exists a function >that will very accurately calculate CPU usage in NT...If I can find it, I'll let >you know. :) See my response to Tom. I am not talking about I/O wait time. But without turning this into an operating system memory management lecture, think about this: Every time a program page faults, it _must_ execute more instructions than it normally would, because it traps into the operating system to do the stuff needed to handle the page fault. If the page is in memory, but not in the process resident set, this is handled very efficiently. If the page has to be physically read in, this is harder as we have to allocate a buffer, and do lots of other things as well. Some of this "extra" computation gets billed back to the process that caused it. It isn't really "system" overhead, because if the program was better behaved it wouldn't happen (as opposed to a user I/O operation which is definitely caused by a user's program executing an I/O instruction). There are many reasons for cpu time variability, from cache to context switching, to TLB cluing, to poor cache aliasing, to system overhead caused by memory starvation.
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.