| msg148369 - (view) |
Author: Antoine Pitrou (pitrou) *  |
Date: 2011-11-26 00:02 |
| This patch uses an accurate POSIX clock if possible in the timeit module. |
|
|
| msg148381 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2011-11-26 06:13 |
| So does the accuracy outweigh using a Python function to call the actual clock function? (and usuable -> usable) |
|
|
| msg148386 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2011-11-26 09:41 |
| Well, you only call the clock at the begining and end of a timing run, not at each iteration. |
|
|
| msg148390 - (view) |
Author: Charles-François Natali (neologix) * |
Date: 2011-11-26 10:56 |
| _clocks = ['CLOCK_PROCESS_CPUTIME_ID', 'CLOCK_MONOTONIC_RAW', 'CLOCK_MONOTONIC', 'CLOCK_REALTIME'] Beware, we're mixing CPU time and wall-clock time: $ ./python -c "from time import *; id = CLOCK_REALTIME; t = clock_gettime(id); sleep(1); print(clock_gettime(id) - t)" 1.0011036396026611 $ ./python -c "from time import *; id = CLOCK_PROCESS_CPUTIME_ID; t = clock_gettime(id); sleep(1); print(clock_gettime(id) - t)" 9.480300000003217e-05 Right now, timeit measures wall-clock time: """ On either platform, the default timer functions measure wall clock time, not the CPU time. [...] On Unix, you can use clock() to measure CPU time. """ With CLOCK_PROCESS_CPUTIME_ID: - depending on the platform, we'll measure either wall-clock time or CPU time - preemtion, blocking syscalls, etc won't be accounted for (so, for example, I/O-related tests will be meaningless) |
|
|
| msg148391 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2011-11-26 11:00 |
| > With CLOCK_PROCESS_CPUTIME_ID: > - depending on the platform, we'll measure either wall-clock time or > CPU time Indeed. I thought CPU time would be more useful (and that's the point of the patch) but perhaps it breaks the spec. > - preemtion, blocking syscalls, etc won't be accounted for (so, for > example, I/O-related tests will be meaningless) But does it include kernel CPU time for the given process? |
|
|
| msg148392 - (view) |
Author: Charles-François Natali (neologix) * |
Date: 2011-11-26 11:12 |
| > Indeed. I thought CPU time would be more useful (and that's the point > of the patch) Ah, OK. Then you should probably rename the issue "make timeit measure CPU time", or something like that, because I really thought this issue was about using a more accurate clock (less jitter, can't go backward, etc). And also update the documentation :-) > but perhaps it breaks the spec. Well, I almost never use timeit so I can't make a call, but that's definitely a semantics change, and this may puzzle some users, especially since it will really depend on the OS/kernel version in use (and so it won't be documented). > But does it include kernel CPU time for the given process? Yes. But it won't be reliable, for example, to measure the performance of a new readinto() implentation, since time spent by the process in 'S' or 'D' state won't be accounted for. |
|
|
| msg148393 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2011-11-26 12:34 |
| > > But does it include kernel CPU time for the given process? > > Yes. But it won't be reliable, for example, to measure the performance > of a new readinto() implentation, since time spent by the process in > 'S' or 'D' state won't be accounted for. Then I'm not sure this is a good idea anymore. |
|
|
| msg148471 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2011-11-28 09:18 |
| I think this should be rejected. |
|
|
| msg148519 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2011-11-28 22:40 |
| Are CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC and CLOCK_REALTIME more accurate than gettimeofday (time.time)? |
|
|
| msg148547 - (view) |
Author: Charles-François Natali (neologix) * |
Date: 2011-11-29 08:22 |
| > Are CLOCK_MONOTONIC_RAW, CLOCK_MONOTONIC and CLOCK_REALTIME more accurate than gettimeofday (time.time)? Actually, on Linux gettimeofday() returns CLOCK_REALTIME. As for CLOCK_MONOTONIC{_RAW}, they're guaranteed not to go backward (NTP and such). But I think Antoine was referring to CPU time vs wall clock time (but see comments above while this is probably a bad idea). > I think this should be rejected. Agreed. |
|
|
| msg148550 - (view) |
Author: Antoine Pitrou (pitrou) * |
Date: 2011-11-29 10:40 |
| Ok, closing. |
|
|