Issue2643

classification
Title: time.clock() returning The Wrong Thing on Linux
Type: behaviour Severity: normal
Components: Documentation, Library Versions: Jython 2.7
Milestone:
process
Status: open Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: jeff.allen, zsd
Priority: normal Keywords:

Created on 2017-11-19.20:21:03 by zsd, last changed 2018-02-25.20:54:46 by jeff.allen.

Messages
msg11661 (view) Author: Jim (zsd) Date: 2017-11-19.20:21:02
www.jython.org/docs/library/time.html says

time.clock()

On Unix, return the current processor time as a floating point number expressed in seconds. The precision, and in fact the very definition of the meaning of “processor time”, depends on that of the C function of the same name, but in any case, this is the function to use for benchmarking Python or timing algorithms.

Now, admittedly Linux is not Unix (in some legal sense), but one might expect it to behave that way.  However, on my system using Python I see results like
>>> from time import clock
>>> clock()
0.008841
>>> clock()
0.009116
>>> clock()
0.009375

but using jython I see
>>> from time import clock
>>> clock()
0.0
>>> clock()
1.96381048
>>> clock()
7.051992804

which contradicts the documentation above.
msg11662 (view) Author: Jeff Allen (jeff.allen) Date: 2017-11-19.22:23:22
As implemented, time.clock() is giving you wall-clock time. I'm sure that's the best we could do at the time it was written (looks old).

Interesting question. If you want a work-around, I found this worked:
>>> from java.lang.management import ManagementFactory as MF
>>> tb = MF.getThreadMXBean()
>>> tb.isThreadCpuTimeSupported()
True
>>> tb.getCurrentThreadCpuTime()
3421875000L
>>> tb.getCurrentThreadCpuTime()*1e-9
3.484375
>>> tb.getCurrentThreadCpuTime()*1e-9
3.5
>>> tb.getCurrentThreadCpuTime()*1e-9
3.515625

It might be useful to re-implement time.clock() this way, if it is available on all major platforms.
msg11663 (view) Author: Jim (zsd) Date: 2017-11-19.22:38:00
Since the documentation differentiates what this does on windows from what it does on Unix, I would think all non-windows "major platforms" would be OK with that.  But perhaps some MacOS or BSD or ??? user might be able to contradict me.
msg11665 (view) Author: Jeff Allen (jeff.allen) Date: 2017-11-20.19:29:30
The dirty secret here is that this is vintage CPython documentation, re-badged (note the v2.5.2), and we don't have time to maintain a variant.

Our biggest documentation bug is not sending people to the CPython version! Over there, it masy be a defect not to state that behaviours documented as "does what the C library does" are CPython implementation details (or it may just be obvious). I should have made clear my little experiment was on Windows. However, the "platform" of Jython is Java, for many purposes (but not sadly not the composing of file names). So if there's a variant, we'd like a Java variant.

Thanks for raising it though, as I like the possibility of using the platform instrumentation, if generally available, and I hadn't realised how easy might be, at least if thread time is what you want.
msg11666 (view) Author: Jim (zsd) Date: 2017-11-20.21:01:03
I did notice a remarkable similarity.  Having said that, I would think it makes sense, if one is to believe that jython is an implementation of Python (with extensions), as opposed to another language which looks remarkably like Python.

I see a comment on the all-knowing stackoverglow which claims time.clock() is deprecated in Python 3.3.

Having said all that, when you say "it masy be a defect not to state that behaviours documented as "does what the C library does" are CPython implementation details (or it may just be obvious)", the way I read that you are saying CPython is not Python.  I was under the impression that (C)Python is the definitive definition of the language, and that functions in (C)Python are exactly what the Python docs say, and the fact that (the default C)Python is implemented in C is not material.
I admit I could be horrible confused on that point.

Cheers.
msg11667 (view) Author: Jeff Allen (jeff.allen) Date: 2017-11-21.09:14:46
Technically CPython is the "reference implementation" of Python. This title rather assumes there is a formal specification. The nearest thing we have is the manual (meaning the Language Reference and Library Reference). 

CPython makes a lot of choices the documents don't specify. E.g. what are the allowable argument types in str.split, or unicode.split?

There are things in the manual explicitly marked as details of CPython not all implementations have to reproduce, for example here: https://docs.python.org/3/reference/datamodel.html#objects-values-and-types . It is also possible to have forgotten to insert such a note when it is deserved.

In the interests of a quiet life and painless re-use, Jython reproduces the behaviour of CPython if it possibly can, and avoids going beyond in any major ways, except for things we think fundamental to a JVM implementation (like memory management).

So in this case, if wall-clock time is acceptable for CPython on Windows, and CPU time on Unix, either might be acceptable for Jython, or something natural to the Java platform might be better.
msg11668 (view) Author: Jim (zsd) Date: 2017-11-21.23:00:35
Thanks for your information.
I guess I would say that "CPython is the "reference implementation" of Python." and "In the interests of a quiet life and painless re-use, Jython reproduces the behaviour of CPython if it possibly can" it would be nice to use the code you suggest in your first response for clock(), at least on any systems that support it.  I think while it is annoying that the behaviour between Unix and Windows varies, that is a bit less problematical (especially given the documentation of it) than Jython and CPython disagreeing.

However, it is much less work for me to say that than for someone to implement that :-)

I guess I've probably said everything useful that I can on this, so unless someone has an explicit question for me, I'm probably done.

Thanks for all your replies on this topic.
msg11717 (view) Author: Jeff Allen (jeff.allen) Date: 2018-02-25.20:54:46
I propose we fix this (when we do) using java.lang.management where available. The divergence from CPython would be that Jython reports pre-thread time. 

There may be advantages to that, in that garbage collection noise is excluded. (Others will think that's cheating.)
History
Date User Action Args
2018-02-25 20:54:46jeff.allensetresolution: accepted
messages: + msg11717
milestone: Jython 2.7.0 ->
2017-11-21 23:00:36zsdsetmessages: + msg11668
2017-11-21 09:14:47jeff.allensetmessages: + msg11667
2017-11-20 21:01:04zsdsetmessages: + msg11666
2017-11-20 19:29:31jeff.allensetmessages: + msg11665
2017-11-19 22:38:01zsdsetmessages: + msg11663
2017-11-19 22:23:22jeff.allensetpriority: normal
nosy: + jeff.allen
messages: + msg11662
components: + Library, - Core
2017-11-19 20:21:03zsdcreate