[Python-Dev] Python Benchmarks (original) (raw)

Fredrik Lundh fredrik at pythonware.com
Sat Jun 3 11:09:42 CEST 2006

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 clockt, 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); }

?

More information about the Python-Dev mailing list