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

Timing off by factor of 100 on windows #33

Closed
Flourish38 opened this issue Jun 10, 2024 · 1 comment · Fixed by #44
Closed

Timing off by factor of 100 on windows #33

Flourish38 opened this issue Jun 10, 2024 · 1 comment · Fixed by #44

Comments

@Flourish38
Copy link

Flourish38 commented Jun 10, 2024

At least, I assume it's a windows issue. I tested it on a Ubuntu system and did not have the same issue.

Minimal Example:

import birl
import birl/duration
import gleam/erlang/process
import gleam/io
import gleam/string

// Based on https://github.com/bcpeinhardt/learn_otp_with_gleam/blob/681c23174fb24d0f7e92ca581fd71306eb4d3063/src/tasks.gleam#L158
fn time(name: String, f: fn() -> a) -> a {
  let start = birl.now()
  let x = f()
  let end = birl.now()
  io.println(name <> " start:\t" <> birl.to_naive_time_string(start))
  io.println(name <> " end:  \t" <> birl.to_naive_time_string(end))
  let difference = birl.difference(end, start) |> duration.decompose
  io.println(name <> " took: \t" <> string.inspect(difference))
  x
}

pub fn main() {
  // Sleep for 2 seconds
  time("timing test", fn() { process.sleep(2000) })
}

Output on Ubuntu system (expected):

timing test start:      15:07:18.823
timing test end:        15:07:20.853
timing test took:       [#(2, Second), #(28, MilliSecond), #(539, MicroSecond)]

Output on Windows system:

timing test start:      15:07:51.380
timing test end:        15:07:53.399
timing test took:       [#(20, MilliSecond), #(174, MicroSecond)]

As you can see, printing the time works fine. It's just the difference that is the issue.

I'm not experienced enough to diagnose exactly what is going on, but I assume that the Duration type that normally takes microseconds is being given 100 microsecond intervals.

@WadeGulbrandsen
Copy link
Contributor

WadeGulbrandsen commented Dec 12, 2024

I came across the same issue when I was timing my solutions for Advent of Code. I didn't think my Windows computer should be so much faster than my Linux VM.

I think the issue is that the monotonic_now() function is assuming that the values returned by erlang:monotonic_time() and erlang:system_info(start_time) are always in nanoseconds. That's the case on Linux but other operating systems use different time units so dividing by 1000 only get's the expected result on Linux.

Instead of dividing by 1000 the time can be converted using erlang:convert_time_unit(Time, native, microsecond).

I'm at work right now but I'll see about making a PR to fix this tonight.

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

Successfully merging a pull request may close this issue.

2 participants