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

Crystal can't measure time below 1100 nanoseconds #7687

Closed
TheOnlyArtz opened this issue Apr 17, 2019 · 6 comments
Closed

Crystal can't measure time below 1100 nanoseconds #7687

TheOnlyArtz opened this issue Apr 17, 2019 · 6 comments

Comments

@TheOnlyArtz
Copy link

TheOnlyArtz commented Apr 17, 2019

Hey, I've done a little experiment with a friend where we tried to iterate the biggest number possible and check the time it takes, we go to UInt128, it went like:

iter : UInt128 = 0_u128

start = Time.monotonic
        UInt128::MAX.times {iter += 1}
elapsed = Time.monotonic - start


puts "Time took to iterate #{iter} times => #{elapsed.nanoseconds}"

The run took 1100 nanoseconds, I was pretty impressed, I thought it was pretty good, but then a friend ran in on Rust and it took 89 nanoseconds, I thought it's impossible and tried to run the crystal binary again (compiled using --release), I've got 1100 again.. and again, and again.

until eventually, I went down to UInt32 in order to be even "faster" and I still got the same result, 1100 nanoseconds, this must be an issue with Crystal, I tried the Time.measure method too and it gave me 1100 at the minimum too!

Runs:
UInt128:
image

UInt32:
image

@TheOnlyArtz
Copy link
Author

Crystal 0.27.0 btw.

@asterite
Copy link
Member

What's your OS? And what does running puts Time.measure { } with --release mode give you? I get times like 54 nanoseconds and 80 nanoseconds.

@TheOnlyArtz
Copy link
Author

I ran it on a WSL, every time compiled with --release, it's Debian.

@Blacksmoke16
Copy link
Member

Might be something to do with WSL then. On Debian proper, it's around 40-60 ns.

@straight-shoota
Copy link
Member

This is probably #7377 and already fixed. Please try with 0.28.0

@TheOnlyArtz
Copy link
Author

TheOnlyArtz commented Apr 18, 2019

This is probably #7377 and already fixed. Please try with 0.28.0

Yep, it is fixed, thank you :)

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

No branches or pull requests

4 participants