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

Larger system time than runtime reported #515

Open
haampie opened this issue May 24, 2022 · 5 comments
Open

Larger system time than runtime reported #515

haampie opened this issue May 24, 2022 · 5 comments

Comments

@haampie
Copy link

haampie commented May 24, 2022

I'm consistently seeing:

  Time (mean ± σ):     289.0 ms ±   7.6 ms    [User: 243.0 ms, System: 862.1 ms]
  Range (min … max):   280.8 ms … 299.9 ms    10 runs

a large system time of 862.1ms, even though mean runtime is 289ms. Why is this?

@sharkdp
Copy link
Owner

sharkdp commented May 24, 2022

That is certainly possible if multiple cores are involved. You should see a similar behavior using time. User and system time are summed up across all cores.

We should really document this somehow (see also #443).

Example to reproduce using stress:

system > real time

▶ hyperfine "stress --vm 2 --timeout 1" 
Benchmark 1: stress --vm 2 --timeout 1
  Time (mean ± σ):      1.006 s ±  0.002 s    [User: 0.218 s, System: 1.781 s]
  Range (min … max):    1.002 s …  1.008 s    10 runs

user > real time

▶ hyperfine "stress --cpu 2 --timeout 1"  
Benchmark 1: stress --cpu 2 --timeout 1
  Time (mean ± σ):      1.001 s ±  0.000 s    [User: 1.987 s, System: 0.000 s]
  Range (min … max):    1.001 s …  1.001 s    10 runs

@haampie
Copy link
Author

haampie commented May 24, 2022

Hm, I was aware, but I thought the application was single-threaded. Maybe I'm mistaken...

$ time taskset -c 0 julia -O3 example.jl
1.0

real	0m0.282s
user	0m0.206s
sys	0m0.058s

$ time julia -O3 example.jl
1.0

real	0m0.284s
user	0m0.222s
sys	0m0.881s

Sorry for the noise :D

@haampie haampie closed this as completed May 24, 2022
@sharkdp
Copy link
Owner

sharkdp commented May 24, 2022

Sorry for the noise :D

No reason to apologize. I actually think this ticket should be left open, as a reminder to update the documentation.

@sharkdp sharkdp reopened this May 24, 2022
@sharkdp
Copy link
Owner

sharkdp commented May 24, 2022

Your benchmark is quite interesting. It's actually not faster using multiple threads, it just spends a lot of time in kernel mode? Strange.

@haampie
Copy link
Author

haampie commented May 24, 2022

It's probably a filesystem quirk

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