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

Timings ? #47

Open
g1mv opened this issue Feb 2, 2018 · 3 comments
Open

Timings ? #47

g1mv opened this issue Feb 2, 2018 · 3 comments

Comments

@g1mv
Copy link

g1mv commented Feb 2, 2018

Are timings done by calculating the actual process time or an absolute time ?
I'm just wondering as a quick look at the code made me think it might be the latter case. That could be problematic as a heavily or variably loaded test machine would generate distorted results.

@inikep
Copy link
Owner

inikep commented Feb 5, 2018

Time is measured with:
QueryPerformanceCounter for Windows
mach_absolute_time for macOS
clock_gettime(CLOCK_MONOTONIC) for Linux

@g1mv
Copy link
Author

g1mv commented Feb 5, 2018

This might be an issue then, because the timings cannot be reliable if anything else runs on the testing machine, as these functions do not count CPU times but absolute times. I actually encountered the problem a while ago and made a simple lib (cputime) to access multiplatform CPU times.
Basically, on Linux and MacOS, you can use getrusage() and check the ru_utime value; and on Windows, GetProcessTimes() will give user time values as well. These functions are not microsecond accurate and are certainly less accurate than the ones you're using, but they have a big advantage which is not being dependent on the external load of your testing machine, i.e. should be immune to load variations and give consistent results. That's what should be expected from a benchmark application I suppose.
What do you think ?

@inikep
Copy link
Owner

inikep commented Feb 6, 2018

Currently it works well (for lzbench and TurboBench) because we set realtime priority and assume that we are using only a single core. Glza is only compressor that uses multi-core but it's slow anyway. The task of comparing compression on multi-core is much harder.

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

2 participants