[Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()? (original) (raw)
Cameron Simpson cs at zip.com.au
Sat Mar 31 01:44:00 CEST 2012
- Previous message: [Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
- Next message: [Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 30Mar2012 15:21, Guido van Rossum <guido at python.org> wrote: | On Fri, Mar 30, 2012 at 2:43 PM, Cameron Simpson <cs at zip.com.au> wrote: | > Given the subtlety sought for various purposes, people should be | > calling: | > T = time.getclock(flags) | > and then later calling: | > T.now() | > to get their float. | > | > That way people can: | > - request a set of the three characteristics above | > - inspect what they get back (it should have all the requested flags, | > but unrequested flags may be set or not depending on the underlying | > facility) | > Obviously this should return None or raise an exception if the flag | > set can't be met. | > | > Then users can request a less featured clock on failure, depending on | > what aspects of the clock are most desirable to their use case. Or of | > course fail if fallback is not satisfactory. [...] | I like this out-of-the-box thinking. But I'm still wondering if there | really are enough flags for this to be worth it. If there are, great, | the API is pretty. But if there are only 2 or 3 flag combinations that | make actual sense, let's forget it.
There are at least three characteristics listed above. There are several use cases described in the long discussions.
I don't think we should be saying "we will only support these 3 thought-of use cases and the others are too hard/weird/perverse/rare". We should be saying: we can characterise clocks in these very few ways. Ask for a clock of some kind. We will provide one (abitrarily, though perhaps preferring higher precision) that satisfies the request if available.
I can easily envisage calling code as simple as this:
T = getclock(T_MONOTONIC|T_HIGHRES) or getclock(T_MONOTONIC)
to do my own fallback for my own use case if we went with returning None if there is no satisfactory clock.
If I need monotonic (for example) my code is in NO WAY helped by being handed something that sometimes is not monotonic; to make my code reliable I would need to act as though I wasn't getting a montonic clock in the first place. No win there at all.
This has the following advantages:
it removes all policy from the PEP, at least at the core
it makes things totally clear and concise at the calling end; the clock characterists are right there in front of the reader
policy is in the hands of the user where it belongs, and is easy to specify into the bargain
it avoids the horrendous ideas mooted of asking for something called monotonic and getting sometime only mostly monotonic, and the equivalent flavours for the other flags
implementation of the PEP is in principle as easy as a table of clock wrappers with the flags each supports. Loop over the table until one matches all the requested flags, or return None.
for higher quality of implementation you embed policy in the convenience function, not the getclock() function To take your suggestion of: Another out-of-the-box idea, going back to simplicity: have just one new function, time.hrtimer(), which is implemented using the highest-resolution timer available on the platform, but with no strong guarantees.
Example: T = time.hrtimer() which would provide the "best" hires timer. You'd give it an optional flag argument for additional flags so that you could request the most-hires timer matching the flags. This is like: T = time.getclock(T_HIRES) except that is makes clear your preferred attribute.
So internally one would have:
clock wrappers for the platform specific facilities, with the constructors being singletons or not as suits the facility
a list of the wrappers with their flag sets specifiying what clock attributes they offer
for the .hrtimer([flags]) or .monotonic([flags]) calls they each have their own list of the clock wrapper, ordered on most-hires or best-monotonic, as the implementor sees fit
That gets you:
- arbitrary user case support
- convenience functions for common policies
| It may jump, move back, drift, change its rate, or roll | over occasionally. We try to use the implementation that's got the | fewest problems, but we don't try to hide its deficiencies, and | nothing suitable exists, it may be equivalent to time.time(). If the | times you measure are too weird, measure again. For scheduling things | a day or more in the future, you should use time.time() instead.
Getting ugly. This is why I think we should not be offering only what we think the user may want, especially when we offer something loose and rubbery like this.
Instead, get the user to ask. The platform timers can all be well characterised with respect to the flags suggested above; you only need to tabulate what timers offer what behaviours.
By all means offer convenience functions providing common choices, but don't make those the only choices. Let the user ask for anything; if the platform can't support it that's a pity, but leave the user the choice of asking for less or making whatever other decision suits them.
| One issue that hasn't had enough attention: scope of a timer. If two | processes running on the same machine ask for the time, do the values | they see use the same epoch, or is the epoch dependent on the process? | Some code I saw in timemodule.c for working around Windows clocks | rolling over seem to imply that two processes may not always see the | same timer value. Is there a use case where this matters?
Make the epoch available in the clock wrapper as a property. At least then there's a mechanism for reconciling things. Don't try to mandate something that possibly can't be mandated.
Cheers,
Cameron Simpson <cs at zip.com.au> DoD#743 http://www.cskk.ezoshosting.com/cs/
My computer always does exactly what I tell it to do but sometimes I have trouble finding out what it was that I told it to do. - Dick Wexelblat <rlw at ida.org>
- Previous message: [Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
- Next message: [Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]