You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've got a benchmark comparison where one side has a mean CPU time of 1.8ns and the other 2.2ns. compare.py reports their "OVERALL GEOMEAN" difference 1.0.
compare.py truncates to integer nanosecond resolution when computing geomean, so it will be inaccurate for many "fast" benchmarks.
System
Linux, but doesn't matter.
To reproduce
Steps to reproduce the behavior:
Run two benchmarks with low single digit timings, ideally with sub-nanosecond differences. The OVERALL_GEOMEAN will tend to be 0.0, 1.0, or -1.0.
I think compare.py only needs to support the units in benchmark JSON. Implementing the C++ code here again in Python to achieve the same effect would be easy:
Oops, that is quite unfortunate :)
I guess it would be fine to hand-roll our own timeunit-to-seconds function then.
Please feel free to look into it if you want.
The pandas.Timedelta class truncates to integral nanoseconds, which throws
away sub-nanosecond precision present in benchmark JSON. Switch to
floating point multiplication, which preserves it.
Fixes#1482
Tentatively fixes#1477.
Describe the bug
I've got a benchmark comparison where one side has a mean CPU time of 1.8ns and the other 2.2ns.
compare.py
reports their "OVERALL GEOMEAN" difference 1.0.compare.py truncates to integer nanosecond resolution when computing geomean, so it will be inaccurate for many "fast" benchmarks.
System
Linux, but doesn't matter.
To reproduce
Steps to reproduce the behavior:
Run two benchmarks with low single digit timings, ideally with sub-nanosecond differences. The OVERALL_GEOMEAN will tend to be 0.0, 1.0, or -1.0.
Expected behavior
OVERALL_GEOMEAN is a correct result.
Additional context
The issue is here:
benchmark/tools/gbench/report.py
Lines 155 to 162 in db55c89
The
pandas.Timedelta
type stores integral (int64) values at nanosecond resolution. See https://github.com/pandas-dev/pandas/blob/28331e0cc7aa0729968565bbd1278b3b6239c823/pandas/_libs/tslibs/timedeltas.pyi#L84I think the OVERALL_GEOMEAN has always had this bug. See #1289.
While
pandas.Timedelta
supports an impressive list of units I don't thinkcompare.py
needs that generality. For what Pandas supports see: https://github.com/pandas-dev/pandas/blob/28331e0cc7aa0729968565bbd1278b3b6239c823/pandas/_libs/tslibs/timedeltas.pyi#L19-L61I think
compare.py
only needs to support the units in benchmark JSON. Implementing the C++ code here again in Python to achieve the same effect would be easy:benchmark/include/benchmark/benchmark.h
Lines 1817 to 1843 in 4366d66
From there, rewriting
get_timedelta_field_as_seconds
to preserve resolution is also easy.Happy to work on this, as I've been looking at these "strange" geomean values in compare.py output the past few days and wondering about it. :)
Screenshots
Here is an example showing the issue:
The text was updated successfully, but these errors were encountered: