Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

PEP 418: Add monotonic clock

 

 

First page Previous page 1 2 3 4 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded


victor.stinner at gmail

Mar 26, 2012, 4:32 PM

Post #1 of 79 (2672 views)
Permalink
PEP 418: Add monotonic clock

Hi,

I started to write the PEP 418 to clarify the notions of monotonic and
steady clocks.

The PEP is a draft and everyone is invited to contribute!

http://www.python.org/dev/peps/pep-0418/
http://hg.python.org/peps/file/tip/pep-0418.txt

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Mar 26, 2012, 5:16 PM

Post #2 of 79 (2630 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
>
> The PEP is a draft and everyone is invited to contribute!

time.steady() doesn't fit the benchmarking use case: it looks like we
have to decide between stability and clock resolution.

QueryPerformanceCounter() has a good resolution for benchmarking, but
it is not monotonic and so GetTickCount64() would be used for
time.steady(). GetTickCount64() is monotonic but has only a resolution
of 1 millisecond.

We might add a third new function which provides the most accurate
clock with or without a known starting point. We cannot use
QueryPerformanceCounter() to enhance time.time() resolution because it
has an unknown starting point.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


scott+python-dev at scottdial

Mar 26, 2012, 5:23 PM

Post #3 of 79 (2643 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

On 3/26/2012 7:32 PM, Victor Stinner wrote:
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.

"""
time.steady
This clock advances at a steady rate relative to real time. It may be
adjusted.
"""

Please do not call this "steady". If the clock can be adjusted, then it
is not "steady" by any acceptable definition. I cannot fathom the
utility of this function other than as a function that provides an
automatic fallback from "time.monotonic()". More importantly: this
definition of "steady" is in conflict with the C++0x definition of
"steady" that is where you sourced this named from![1]

"""
time.steady(strict=False) falls back to another clock if no monotonic
clock is not available or does not work, but it does never fail.
"""

As I say above, that is so far away from what "steady" implies that this
is a misnomer. What you are describing is a best-effort clock, which
sounds a lot more like the C++0x "high resolution" clock.

"""
time.steady(strict=True) raises OSError if monotonic clock fails or
NotImplementedError if the system does not provide a monotonic clock
"""

What is the utility of "strict=True"? If I wanted that mode of
operation, then why would I not just try to use "time.monotonic()"
directly? At worst, it generates an "AttributeError" (although that is
not clear from your PEP). What is the use case for "strict=True" that is
not covered by your "time.monotonic()"?

If you want to define new clocks, then I wish you would use the same
definitions that C++0x is using. That is:

system_clock = wall clock time
monotonic_clock = always goes forward but can be adjusted
steady_clock = always goes forward and cannot be adjusted
high_resolution_clock = steady_clock || system_clock

Straying from that is only going to create confusion. Besides that, the
one use case for "time.steady()" that you give (benchmarking) is better
served by a clock that follows the C++0x definition. As well, certain
kinds of scheduling/timeouts would be better implemented with the C++0x
definition for "steady" rather than the "monotonic" one and vice-versa.

Rather, it seems you have a particular use-case in mind and have settled
on calling that a "steady" clock despite how it belies its name.

[1]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady

"""
Objects of class steady_clock represent clocks for which values of
time_point advance at a steady rate relative to real time. That is, the
clock may not be adjusted.
"""

--
Scott Dial
scott [at] scottdial
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


zooko at zooko

Mar 26, 2012, 7:26 PM

Post #4 of 79 (2639 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

>  system_clock = wall clock time
>  monotonic_clock = always goes forward but can be adjusted
>  steady_clock = always goes forward and cannot be adjusted
>  high_resolution_clock = steady_clock || system_clock

Note that the C++ standard deprecated monotonic_clock once they
realized that there is absolutely no point in having a clock that
jumps forward but not back, and that none of the operating systems
implement such a thing -- instead they all implement a clock which
doesn't jump in either direction.

http://stackoverflow.com/questions/6777278/what-is-the-rationale-for-renaming-monotonic-clock-to-steady-clock-in-chrono

In other words, yes! +1! The C++ standards folks just went through the
process that we're now going through, and if we do it right we'll end
up at the same place they are:

http://en.cppreference.com/w/cpp/chrono/system_clock

"""
system_clock represents the system-wide real time wall clock. It may
not be monotonic: on most systems, the system time can be adjusted at
any moment. It is the only clock that has the ability to map its time
points to C time, and, therefore, to be displayed.

steady_clock: monotonic clock that will never be adjusted

high_resolution_clock: the clock with the shortest tick period available
"""

Note that we don't really have the option of providing a clock which
is "monotonic but not steady" in the sense of "can jump forward but
not back". It is a misunderstanding (doubtless due to the confusing
name "monotonic") to think that such a thing is offered by the
underlying platforms. We can choose to *call* it "monotonic",
following POSIX instead of calling it "steady", following C++.

Regards,

Zooko
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


anacrolix at gmail

Mar 26, 2012, 7:59 PM

Post #5 of 79 (2632 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

So does anyone care to dig into the libstd++/boost/windoze implementation
to see how they each did steady_clock?


scott+python-dev at scottdial

Mar 26, 2012, 8:36 PM

Post #6 of 79 (2636 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

On 3/26/2012 10:59 PM, Matt Joiner wrote:
> So does anyone care to dig into the libstd++/boost/windoze
> implementation to see how they each did steady_clock?

The Boost implementation can be summarized as:

system_clock:

mac = gettimeofday
posix = clock_gettime(CLOCK_REALTIME)
win = GetSystemTimeAsFileTime

steady_clock:

mac = mach_absolute_time
posix = clock_gettime(CLOCK_MONOTONIC)
win = QueryPerformanceCounter

high_resolution_clock:

* = { steady_clock, if available
system_clock, otherwise }

Whether or not these implementations meet the specification is an
exercise left to the reader..

--
Scott Dial
scott [at] scottdial
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


anacrolix at gmail

Mar 26, 2012, 8:54 PM

Post #7 of 79 (2661 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

Cheers, that clears things up.


jyasskin at gmail

Mar 26, 2012, 10:51 PM

Post #8 of 79 (2648 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

FWIW, I'm not sure you're the right person to drive time PEPs. You
don't seem to have come into it with much knowledge of time, and it's
taken several repetitions for you to take corrections into account in
both this discussion and the Decimal/datetime representation PEP.

On Mon, Mar 26, 2012 at 4:32 PM, Victor Stinner
<victor.stinner [at] gmail> wrote:
> Hi,
>
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
>
> The PEP is a draft and everyone is invited to contribute!
>
> http://www.python.org/dev/peps/pep-0418/
> http://hg.python.org/peps/file/tip/pep-0418.txt
>
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/jyasskin%40gmail.com
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

Mar 26, 2012, 11:48 PM

Post #9 of 79 (2623 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

On Tue, Mar 27, 2012 at 3:51 PM, Jeffrey Yasskin <jyasskin [at] gmail> wrote:
> FWIW, I'm not sure you're the right person to drive time PEPs. You
> don't seem to have come into it with much knowledge of time, and it's
> taken several repetitions for you to take corrections into account in
> both this discussion and the Decimal/datetime representation PEP.

The main things required to be a PEP champion are passion and a
willingness to listen to expert feedback and change course in
response. If someone lacks the former, they will lose steam and their
PEP will eventually be abandoned. If they don't listen to expert
feedback, then their PEP will ultimately be rejected (sometimes a PEP
will be rejected anyway as a poor fit for the language *despite* being
responsive to feedback, but that's no slight to the PEP author).

Victor has shown himself to be quite capable of handling those aspects
of the PEP process, and the topics he has recently applied himself to
are ones where it is worthwhile having a good answer in the standard
library for Python 3.3.

Cheers,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


p.f.moore at gmail

Mar 27, 2012, 12:14 AM

Post #10 of 79 (2624 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

On 27 March 2012 01:23, Scott Dial <scott+python-dev [at] scottdial> wrote:
> If you want to define new clocks, then I wish you would use the same
> definitions that C++0x is using. That is:
>
> system_clock = wall clock time
> monotonic_clock = always goes forward but can be adjusted
> steady_clock = always goes forward and cannot be adjusted
> high_resolution_clock = steady_clock || system_clock

+1. This seems like an ideal case for following prior art in designing
a Python API.

Paul
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


glyph at twistedmatrix

Mar 27, 2012, 12:17 AM

Post #11 of 79 (2632 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

On Mar 26, 2012, at 10:26 PM, Zooko Wilcox-O'Hearn wrote:

> Note that the C++ standard deprecated monotonic_clock once they
> realized that there is absolutely no point in having a clock that
> jumps forward but not back, and that none of the operating systems
> implement such a thing -- instead they all implement a clock which
> doesn't jump in either direction.

This is why I don't like the C++ terminology, because it seems to me that the C++ standard makes incorrect assertions about platform behavior, and apparently they standardized it without actually checking on platform capabilities.

The clock does jump forward when the system suspends. At least some existing implementations of steady_clock in C++ already have this problem, and I think they all might. I don't think they can fully fix it without kernel changes, either. On linux, see discussion of a possible CLOCK_BOOTTIME in the future. The only current way I know of to figure out how long the system has been asleep is to look at the wall clock and compare, and we've already gone over the problems with relying on the wall clock.

Plus, libstdc++ gives you no portable way to get informed about system power management events, so you can't fix it even if you know about this problem, natch.

Time with respect to power management state changes is something that the PEP should address fully, for each platform.

On the other hand, hopefully you aren't controlling your python-based CNC laser welder from a laptop that you are closing the lid on while the beam is in operation. Not that the PEP shouldn't address it, but maybe it should just address it to say "you're on your own" and refer to a few platform-specific resources for correcting this type of discrepancy. (<https://developer.apple.com/library/mac/#qa/qa1340/_index.html>, <http://msdn.microsoft.com/en-us/library/aa394362.aspx>, <http://upower.freedesktop.org/docs/UPower.html#UPower::Sleeping>).

-glyph


glyph at twistedmatrix

Mar 27, 2012, 1:05 AM

Post #12 of 79 (2657 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

On Mar 27, 2012, at 3:17 AM, Glyph wrote:

> I don't think they can fully fix it without kernel changes

I got really curious about this and went and did some research. With some really platform-specific hackery on every platform, you can mostly figure it out; completely on OS X and Windows, although (as far as I can tell) only partially on Linux and FreeBSD.

I'm not sure if it's possible to make use of these facilities without a Twisted-style event-loop though. If anybody's interested, I recorded the results of my research in a comment on the Twisted ticket for this: <http://twistedmatrix.com/trac/ticket/2424#comment:26>.

-glyph


regebro at gmail

Mar 27, 2012, 2:03 AM

Post #13 of 79 (2655 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

Reading this discussion, my conclusion is that not only us are
confused, but everyone is. I think therefore, that the way forward is
to only expose underlying API functions, and pretty much have no
intelligence at all.

At a higher level, we have two different "desires" here. You may want
a monotonic clock, or you may not care. You may want high resolution,
or you might not care. Which one is more important is something only
you know. Therefore, we must have, at the minimum, a function that
returns the highest resolution monotonic clock possible, as well as a
function that returns the highest resolution system/wall clock
possible. We also need ways to figure out what the resolution is of
these clocks.

In addition to that, you may have the requirement that the monotonic
clock also should not be able to jump forward, but if I understand
things correctly, most current OS's will not guarantee this. You may
also have the requirement that the clock not only does not jump
forward, but that it doesn't go faster or slower. Some clock
implementations will speed up or slow down the monotonic clock,
without jumps, to sync up with the wall clock. It seems only Unix
provides a monotonic clock (CLOCK_MONOTONIC_RAW) that does not get
adjusted at all.

Now between all these requirements, only you know which one is more
important? Do you primarily want a raw monotonic clock, and
secondarily high resolution, or is the resolution more important than
it being monotonic? (Because if you need a high resolution, you are
usually measuring small timeframes, and the clock is more unlikely to
be adjusted, for example).

Since there is no obvious "A is better than B that is better than C"
we first of all have to expose the underlying API's somehow, to allow
people to make their own decisions. Secondly, since apparently not
only python-dev, but many others as well, are a bit confused on this
complex issue, I'm not sure we can provide any high-level functions
that makes a best choice.

As such the proposed time.monotonic() to get the monotonic clock on
the various systems makes a lot of sense to me. It should get the
highest resolution available on the system. Get GetTickCount64() of
available on Windows, else GetTickCount(). The function could have a
raw=False parameter to select between clock_gettime(CLOCK_MONOTONIC)
and clock_gettime(CLOCK_MONOTONIC_RAW) on Unix, and it would get
mach_absolute_time() on OS X.

If no monotonic clock is available, it should raise an error.The same
if you pass in raw=True and there is no monotonic clock that has no
adjustments available.

In the same vein, time.time() should provide the highest resolution
system clock/wall clock available.

We also need functions or attributes to get the resolution of these clocks.


But a time.steady() that tries to get a "best case" doesn't make sense
at this time, as apparently nobody knows what a best case is, or what
it should be called, except that it should apparently not be called
steady(). Since monotonic() raises an error if there is no monotonic
clock available, implementing your own fallback is trivial in any
case.

//Lennart
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

Mar 27, 2012, 6:23 AM

Post #14 of 79 (2637 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

On Tue, Mar 27, 2012 at 7:03 PM, Lennart Regebro <regebro [at] gmail> wrote:
> But a time.steady() that tries to get a "best case" doesn't make sense
> at this time, as apparently nobody knows what a best case is, or what
> it should be called, except that it should apparently not be called
> steady(). Since monotonic() raises an error if there is no monotonic
> clock available, implementing your own fallback is trivial in any
> case.

+1 from me to Lennart's suggestion of mostly just exposing
time.monotonic() without trying to get too clever. Applications that
need a truly precise time source should *never* be reading it from the
host OS (one fairly good solution can be to read your time directly
from an attached GPS device).

However, I think Victor's right to point out that the *standard
library* needs to have a fallback to maintain backwards compatibility
if time.monotonic() isn't available, and it seems silly to implement
the same fallback logic in every module where we manipulate timeouts.
As I concur with others that time.steady() is a thoroughly misleading
name for this concept, I suggest we encapsulate the "time.monotic if
available, time.time otherwise" handling as a "time.try_monotic()"
function.

That's simple clear and explicit: try_monotic() tries to use the
monotic clock if it can, but falls back to time.time() rather than
failing entirely if no monotonic clock is available. This is essential
for backwards compatibility when migrating any current use of
time.time() over to time.monotic(). Yes the monotonic clock is
*better* for many use cases (including timeouts), but you'll usually
be OK with the non-monotonic clock, too (particularly if that's what
you were using anyway in earlier versions). After all, we've survived
this long using time.time() for our timeout calculations, and bugs
associated with clock adjustments are a rather rare occurrence.

Third party libraries that need to support earlier Python versions can
then implementation their own fallback logic (since they couldn't rely
on time.try_monotonic being available either).

The 3.3 time module would then be left with three interfaces:

time.time() # Highest resolution timer available
time.monotonic() # I'm not yet convinced we need the "raw" parameter
but don't much mind either way
time.try_monotonic() # Monotonic is preferred, but non-monotonic
presents a tolerable risk

Regards,
Nick.

--
Nick Coghlan | ncoghlan [at] gmail | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ethan at stoneleaf

Mar 27, 2012, 9:18 AM

Post #15 of 79 (2623 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

Nick Coghlan wrote:
> The 3.3 time module would then be left with three interfaces:
>
> time.time() # Highest resolution timer available
> time.monotonic() # I'm not yet convinced we need the "raw" parameter
> but don't much mind either way
> time.try_monotonic() # Monotonic is preferred, but non-monotonic
> presents a tolerable risk

+1

~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


yselivanov.ml at gmail

Mar 27, 2012, 10:10 AM

Post #16 of 79 (2632 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

On 2012-03-27, at 9:23 AM, Nick Coghlan wrote:

> time.try_monotonic() # Monotonic is preferred, but non-monotonic
> presents a tolerable risk

This function seems unnecessary. It's easy to implement it when
required in your application, hence I don't think it is worth
adding to the stdlib.

-
Yury
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Mar 27, 2012, 10:34 AM

Post #17 of 79 (2622 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.

I replaced time.steady() by time.try_monotonic(). I misunderstood "may
not" in the C++ doc: I understood it as "it may be adjusted by NTP",
whereas it means "it cannot be adjusted". Sorry for the confusion.

I added a time.hires() clock because time.monotonic() and
time.try_monotonic() are not the best clocks for profiling or
benchmarking. For example, on Windows, time.hires() uses
QueryPerformanceCounter() whereas time.monotonic() and
time.try_monotonic() uses GetTickCount[64]().

I added the pseudo-code of each function. I hope that it is easier to
understand than a long text.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ethan at stoneleaf

Mar 27, 2012, 10:35 AM

Post #18 of 79 (2612 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

Yury Selivanov wrote:
> On 2012-03-27, at 9:23 AM, Nick Coghlan wrote:
>
>> time.try_monotonic() # Monotonic is preferred, but non-monotonic
>> presents a tolerable risk
>
> This function seems unnecessary. It's easy to implement it when
> required in your application, hence I don't think it is worth
> adding to the stdlib.

If I understood Nick correctly, time.try_monotonic() is /for/ the
stdlib. If others want to make use of it, fine. If others want to make
their own fallback mechanism, also fine.

~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Mar 27, 2012, 10:45 AM

Post #19 of 79 (2624 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

> What is the utility of "strict=True"? If I wanted that mode of
> operation, then why would I not just try to use "time.monotonic()"
> directly?

I mentioned the strict=True API in the PEP just to list all
propositions, but the PEP only proposes time.monotonic() and
time.try_monotonic(), no the flags API.

> At worst, it generates an "AttributeError" (although that is not clear from your PEP).

I tried to mention when a function is always available or not always
available. Is it better in the last version of the PEP?

>  system_clock = wall clock time
>  monotonic_clock = always goes forward but can be adjusted
>  steady_clock = always goes forward and cannot be adjusted
>  high_resolution_clock = steady_clock || system_clock

I tried to follow these names in the PEP. I don't propose steady_clock
because I don't see exactly which clocks would be used to implement
it, nor if we need to provide monotonic *and* steady clocks. What do
you think?

> Straying from that is only going to create confusion. Besides that, the
> one use case for "time.steady()" that you give (benchmarking) is better
> served by a clock that follows the C++0x definition.

I added a time.hires() clock to the PEP for the benchmarking/profiling
use case. This function is not always available and so a program has
to fallback manually to another clock. I don't think that it is an
issue: Python programs already have to choose between time.clock() and
time.time() depending on the OS (e.g. timeit module and pybench
program).

> As well, certain
> kinds of scheduling/timeouts would be better implemented with the C++0x
> definition for "steady" rather than the "monotonic" one and vice-versa.

Sorry, I don't understand. Which kind of scheduling/timeouts?

The PEP is still a draft (work-in-progress).

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Mar 27, 2012, 10:50 AM

Post #20 of 79 (2640 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

> steady_clock:
>
>  mac = mach_absolute_time
>  posix = clock_gettime(CLOCK_MONOTONIC)
>  win = QueryPerformanceCounter

I read that QueryPerformanceCounter is no so monotonic, and
GetTickCount is preferred. Is it true?

> high_resolution_clock:
>
>  * = { steady_clock, if available
>        system_clock, otherwise }

On Windows, I propose to use QueryPerformanceCounter() for
time.hires() and GetTickCount() for time.monotonic().

See the PEP for other OSes.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Mar 27, 2012, 10:51 AM

Post #21 of 79 (2630 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

2012/3/27 Jeffrey Yasskin <jyasskin [at] gmail>:
> FWIW, I'm not sure you're the right person to drive time PEPs.

I don't want to drive the PEP. Anyone is invited to contribute, as I
wrote in my first message.

I'm completing/rewriting the PEP with all comments.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Mar 27, 2012, 10:55 AM

Post #22 of 79 (2640 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

> The clock does jump forward when the system suspends.  At least some
> existing implementations of steady_clock in C++ already have this problem,
> and I think they all might.
> ....
> Time with respect to power management state changes is something that the
> PEP should address fully, for each platform.

I don't think that Python should workaround OS issues, but document
them correctly. I started with this sentence for time.monotonic():

"The monotonic clock may stop while the system is suspended."

I don't know exactly how clocks behave with system suspend. Tell me if
you have more information.

>  (<https://developer.apple.com/library/mac/#qa/qa1340/_index.html>,
> <http://msdn.microsoft.com/en-us/library/aa394362.aspx>,
> <http://upower.freedesktop.org/docs/UPower.html#UPower::Sleeping>).

I will read these links and maybe add them to the PEP.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


victor.stinner at gmail

Mar 27, 2012, 10:59 AM

Post #23 of 79 (2616 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

> That's simple clear and explicit: try_monotic() tries to use the
> monotic clock if it can, but falls back to time.time() rather than
> failing entirely if no monotonic clock is available.

I renamed time.steady() to time.try_monotonic() in the PEP. It's a
temporary name until we decide what to do with this function.

I also changed it to fallback to time.hires() if time.monotonic() is
not available or failed.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


fuzzyman at voidspace

Mar 27, 2012, 11:00 AM

Post #24 of 79 (2643 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

On 27/03/2012 18:45, Victor Stinner wrote:
> [snip...]
>> Straying from that is only going to create confusion. Besides that, the
>> one use case for "time.steady()" that you give (benchmarking) is better
>> served by a clock that follows the C++0x definition.
> I added a time.hires() clock to the PEP for the benchmarking/profiling
> use case. This function is not always available and so a program has
> to fallback manually to another clock. I don't think that it is an
> issue: Python programs already have to choose between time.clock() and
> time.time() depending on the OS (e.g. timeit module and pybench
> program).

It is this always-having-to-manually-fallback-depending-on-os that I was
hoping your new functionality would avoid. Is time.try_monotonic()
suitable for this usecase?

Michael
>
>> As well, certain
>> kinds of scheduling/timeouts would be better implemented with the C++0x
>> definition for "steady" rather than the "monotonic" one and vice-versa.
> Sorry, I don't understand. Which kind of scheduling/timeouts?
>
> The PEP is still a draft (work-in-progress).
>
> Victor
> _______________________________________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>


--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


anacrolix at gmail

Mar 27, 2012, 11:18 AM

Post #25 of 79 (2620 views)
Permalink
Re: PEP 418: Add monotonic clock [In reply to]

> I renamed time.steady() to time.try_monotonic() in the PEP. It's a
> temporary name until we decide what to do with this function.

How about get rid of it?

Also monotonic should either not exist if it's not available, or always
guarantee a (artificially) monotonic value. Finding out that something is
already known to not work shouldn't require a call and a faked OSError.

First page Previous page 1 2 3 4 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.