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

Measure runtime with best available precision #207

Closed
PragTob opened this issue Apr 7, 2018 · 3 comments
Closed

Measure runtime with best available precision #207

PragTob opened this issue Apr 7, 2018 · 3 comments
Assignees
Milestone

Comments

@PragTob
Copy link
Member

PragTob commented Apr 7, 2018

During #195 we learned about the differences in precision between different systems (some measure in nano seconds, some in milliseconds). We'd like to always use the best precision available to us. Double check for instance with fast function measurements if it really improves things.

This most likely includes reimplementing timer:tc in our new Measure.Time introduced in #204.

It's really simple though:

tc(F) ->
    T1 = erlang:monotonic_time(),
    Val = F(),
    T2 = erlang:monotonic_time(),
    Time = erlang:convert_time_unit(T2 - T1, native, microsecond),
{Time, Val}.

(see how it just always go to microseconds...)

source

The easiest would be to always return the measured time in nano seconds (as that's maximum accuracy afaik). However, that won't roll with our determine_n_times code as it is right now as it checks whenever we get a measurement bigger than 8 with the intention being that when we measure values we have at least some small different between them. However, 1000 is bigger than 8 and would result in us always measuring 1000 or 0 (if the precision is microseconds).

So, the determination of n times likely has the work with the native measurements. For real runtime measurements, we can probably always convert to nanoseconds without losing anything (except maybe memory etc. when the numbers get realllyyyy big).
We could also just store all of them in the native resolution but note down the native resolution in the configuration or so so that formatters etc. can know whatever time they read there.

Getting the native time isn't an official interface though.

It's an interesting problem - I'd like to solve it before 1.0 though because people should get the maximum accuracy their machine is capable of.

@PragTob PragTob added this to the 1.0 milestone Apr 7, 2018
@PragTob
Copy link
Member Author

PragTob commented Apr 8, 2018

Filed an issue with OTP: https://bugs.erlang.org/browse/ERL-608

@devonestes
Copy link
Collaborator

Soooo, do we want to handle this at our level, or try and submit a patch to Erlang? Based on the response to your report, it seems like they're open to it, but want someone else to do it.

@PragTob
Copy link
Member Author

PragTob commented May 10, 2018

👋

I'm already on handling it :) There's a lot to do on our side, PR coming in soon. Helping patch up Erlang of course not out of the question but that'd take a year to land I guess and then only be available on the new OTP version.

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

No branches or pull requests

2 participants