[Coin-discuss] user time vs. system time

[Lou Hafer]

	To add a bit more to Tobias' reply: User time is the time the
processor spends executing your user code. System time is the time the
processor spends executing o/s code on behalf of your process. If your
process is the only process running on a system, then you really should be
counting system time, as any system activity is (presumably) necessary to run
your program. As soon as other processes start to compete for the CPU and
memory hierarchy, there will be costs associated with each context switch
(i.e., the changeover from one process to another).

	Any context switch requires the processor to save the state of your
process, and later restore it when your process is scheduled to run again.
This costs a few hundred to a few thousand (assembly language) instructions,
depending on the details of why/how your process was interrupted.

	In modern systems, what really hurts is that data & instructions
relevant to your process can be flushed from the top levels of the memory
hierarchy. Roughly, you're looking at an order of magnitude slowdown for each
level in the hierarchy. (I.e., O(1) cpu cycles to access L1 cache, O(10) to
access L2, O(100) to access RAM.) Other factors enter in: modern CPUs can
execute more than one instruction/cycle, they try to prefetch in anticipation
of memory accesses, and the width of data paths in the memory hierarchy are a
multiple of the processor word size. Bottom line would be that if another
process flushes your data & instructions out of the top levels of the
hierarchy, you can see a drop in performance of O(10) -- O(1000) until the
top levels (L1, L2, L3 if it exists) repopulate. You'll see a similar effect
if your process is moving large amounts of data between RAM and the CPU ---
the cache hierarchy will not be big enough to hold it. Hence the emphasis on
cache-friendly code.

	Paging (exchange of code and data between RAM and disk) is a whole
different ball game, with delay up around O(100,000). So if there are a lot
of processes competing for space in RAM, and your code/data is paged out and
must then be paged in, the delay to resume is enormous. Arguably, your
process is not really responsible for this activity.

	The cost of cache repopulation would not (to my knowledge) show as
system time, as it will not in general cause a context switch. Paging (a disk
i/o operation) will show as system time.

							Lou