[Python-Dev] Python Benchmarks

M.-A. Lemburg mal at egenix.com
Tue Jun 6 17:15:30 CEST 2006


Fredrik Lundh wrote:
> 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.

This example is a bit misleading, since chances are high that
the benchmark will get a good priority bump by the scheduler.

>> 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?

You should use getrusage() for user and system time or even
better clock_gettime() (the POSIX real-time APIs).

>From the man-page of times:

RETURN VALUE
       The function times returns the number of clock ticks that have
elapsed  since  an  arbitrary
       point  in  the  past.

...

       The number of clock ticks per second can be obtained using
              sysconf(_SC_CLK_TCK);

On my Linux system this returns 100.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Jun 06 2006)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::


More information about the Python-Dev mailing list