Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Perfom walltime measurements in nanoseconds #1060

Open
PhilippWendler opened this issue Jun 28, 2024 · 2 comments
Open

Perfom walltime measurements in nanoseconds #1060

PhilippWendler opened this issue Jun 28, 2024 · 2 comments

Comments

@PhilippWendler
Copy link
Member

Since Python 3.7 there is time.monotonic_ns(), which allows us to use nanoseconds for measuring walltime.

This makes sense only if we switch from using float to Decimal for storing these values, as the main reason why time.monotonic() is less precise is the use of float. This will change the types used in the public API of RunExecutor, but we have documented already that these values can be some arithmetic type and we have not guaranteed them to be floats. So we should be able to do this.

Then we should also return CPU-time measurements as Decimal values. (For these we already read micro- or nanosecond values from the kernel, but loose precision by converting them to float.)

@JawHawk
Copy link
Member

JawHawk commented Aug 27, 2024

@PhilippWendler I would like to work on this.
I have identified the files where time.monotonic() and float is used, but can you please roughly share the areas of changes, as it will provide me with more clarity. Thankyou.

@PhilippWendler
Copy link
Member Author

Sorry for the delay, I am pretty busy right now. I have thought a little bit more about this, and while I still think that we should eventually do this, but I now understand that it is low priority. The reason for this is that double-precision floats provide ~16 decimal digits of precision, so we would not loose measurement precision due to floats unless a run takes more than 100 days, which is extremely unlikely to ever occur. So I tend to say we should wait for a major release for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants