[Python-Dev] Python Benchmarks

[Fredrik Lundh]

Martin v. Löwis wrote:

>> since process time is *sampled*, not measured, process time isn't exactly in-
>> vulnerable either.
> 
> I can't share that view. The scheduler knows *exactly* what thread is
> running on the processor at any time, and that thread won't change
> until the scheduler makes it change. So if you discount time spent
> in interrupt handlers (which might be falsely accounted for the
> thread that happens to run at the point of the interrupt), then
> process time *is* measured, not sampled, on any modern operating system:
> it is updated whenever the scheduler schedules a different thread.

updated with what?  afaik, the scheduler doesn't have to wait for a 
timer interrupt to reschedule things (think blocking, or interrupts that 
request rescheduling, or new processes, or...) -- but it's always the 
thread that runs when the timer interrupt arrives that gets the entire 
jiffy time.  for example, this script runs for ten seconds, usually 
without using any process time at all:

     import time
     for i in range(1000):
         for i in range(1000):
             i+i+i+i
         time.sleep(0.005)

while the same program, without the sleep, will run for a second or two, 
most of which is assigned to the process.

if the scheduler used the TSC to keep track of times, it would be 
*measuring* process time.  but unless something changed very recently, 
it doesn't.  it's all done by sampling, typically 100 or 1000 times per 
second.

> On Linux, process time is accounted in jiffies. Unfortunately, for
> compatibility, times(2) converts that to clock_t, losing precision.

times(2) reports time in 1/CLOCKS_PER_SEC second units, while jiffies 
are counted in 1/HZ second units.  on my machine, CLOCKS_PER_SEC is a 
thousand times larger than HZ.  what does this code print on your machine?

#include <time.h>
#include <sys/param.h>

main()
{
     printf("CLOCKS_PER_SEC=%d, HZ=%d\n", CLOCKS_PER_SEC, HZ);
}

?

</F>