2018-10-01 22:51:08 +08:00
|
|
|
// Copyright 2015 Google Inc. All rights reserved.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
|
|
|
#include "benchmark_runner.h"
|
2021-06-03 21:54:06 +08:00
|
|
|
|
2018-10-01 22:51:08 +08:00
|
|
|
#include "benchmark/benchmark.h"
|
|
|
|
#include "benchmark_api_internal.h"
|
|
|
|
#include "internal_macros.h"
|
|
|
|
|
|
|
|
#ifndef BENCHMARK_OS_WINDOWS
|
2022-10-05 03:43:27 +08:00
|
|
|
#if !defined(BENCHMARK_OS_FUCHSIA) && !defined(BENCHMARK_OS_QURT)
|
2018-10-01 22:51:08 +08:00
|
|
|
#include <sys/resource.h>
|
|
|
|
#endif
|
|
|
|
#include <sys/time.h>
|
|
|
|
#include <unistd.h>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#include <algorithm>
|
|
|
|
#include <atomic>
|
2023-02-07 19:45:18 +08:00
|
|
|
#include <climits>
|
|
|
|
#include <cmath>
|
2018-10-01 22:51:08 +08:00
|
|
|
#include <condition_variable>
|
|
|
|
#include <cstdio>
|
|
|
|
#include <cstdlib>
|
|
|
|
#include <fstream>
|
|
|
|
#include <iostream>
|
2023-02-07 19:45:18 +08:00
|
|
|
#include <limits>
|
2018-10-01 22:51:08 +08:00
|
|
|
#include <memory>
|
|
|
|
#include <string>
|
|
|
|
#include <thread>
|
|
|
|
#include <utility>
|
|
|
|
|
|
|
|
#include "check.h"
|
|
|
|
#include "colorprint.h"
|
|
|
|
#include "commandlineflags.h"
|
|
|
|
#include "complexity.h"
|
|
|
|
#include "counter.h"
|
|
|
|
#include "internal_macros.h"
|
|
|
|
#include "log.h"
|
|
|
|
#include "mutex.h"
|
2021-04-28 16:25:29 +08:00
|
|
|
#include "perf_counters.h"
|
2018-10-01 22:51:08 +08:00
|
|
|
#include "re.h"
|
|
|
|
#include "statistics.h"
|
|
|
|
#include "string_util.h"
|
|
|
|
#include "thread_manager.h"
|
|
|
|
#include "thread_timer.h"
|
|
|
|
|
|
|
|
namespace benchmark {
|
|
|
|
|
|
|
|
namespace internal {
|
|
|
|
|
|
|
|
MemoryManager* memory_manager = nullptr;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
Iteration counts should be `uint64_t` globally. (#817)
This is a shameless rip-off of https://github.com/google/benchmark/pull/646
I did promise to look into why that proposed PR was producing
so much worse assembly, and so i finally did.
The reason is - that diff changes `size_t` (unsigned) to `int64_t` (signed).
There is this nice little `assert`:
https://github.com/google/benchmark/blob/7a1c37028359ca9d386d719a6ad527743cf1b753/include/benchmark/benchmark.h#L744
It ensures that we didn't magically decide to advance our iterator
when we should have finished benchmarking.
When `cached_` was unsigned, the `assert` was `cached_ UGT 0`.
But we only ever get to that `assert` if `cached_ NE 0`,
and naturally if `cached_` is not `0`, then it is bigger than `0`,
so the `assert` is tautological, and gets folded away.
But now that `cached_` became signed, the assert became `cached_ SGT 0`.
And we still only know that `cached_ NE 0`, so the assert can't be
optimized out, or at least it doesn't currently.
Regardless of whether or not that is a bug in itself,
that particular diff would have regressed the normal 64-bit systems,
by halving the maximal iteration space (since we go from unsigned counter
to signed one, of the same bit-width), which seems like a bug.
And just so it happens, fixing *this* bug, fixes the other bug.
This produces fully (bit-by-bit) identical state_assembly_test.s
The filecheck change is actually needed regardless of this patch,
else this test does not pass for me even without this diff.
2019-05-13 17:33:11 +08:00
|
|
|
static constexpr IterationCount kMaxIterations = 1000000000;
|
2023-02-07 19:45:18 +08:00
|
|
|
const double kDefaultMinTime =
|
|
|
|
std::strtod(::benchmark::kDefaultMinTimeStr, /*p_end*/ nullptr);
|
2018-10-01 22:51:08 +08:00
|
|
|
|
|
|
|
BenchmarkReporter::Run CreateRunReport(
|
|
|
|
const benchmark::internal::BenchmarkInstance& b,
|
Iteration counts should be `uint64_t` globally. (#817)
This is a shameless rip-off of https://github.com/google/benchmark/pull/646
I did promise to look into why that proposed PR was producing
so much worse assembly, and so i finally did.
The reason is - that diff changes `size_t` (unsigned) to `int64_t` (signed).
There is this nice little `assert`:
https://github.com/google/benchmark/blob/7a1c37028359ca9d386d719a6ad527743cf1b753/include/benchmark/benchmark.h#L744
It ensures that we didn't magically decide to advance our iterator
when we should have finished benchmarking.
When `cached_` was unsigned, the `assert` was `cached_ UGT 0`.
But we only ever get to that `assert` if `cached_ NE 0`,
and naturally if `cached_` is not `0`, then it is bigger than `0`,
so the `assert` is tautological, and gets folded away.
But now that `cached_` became signed, the assert became `cached_ SGT 0`.
And we still only know that `cached_ NE 0`, so the assert can't be
optimized out, or at least it doesn't currently.
Regardless of whether or not that is a bug in itself,
that particular diff would have regressed the normal 64-bit systems,
by halving the maximal iteration space (since we go from unsigned counter
to signed one, of the same bit-width), which seems like a bug.
And just so it happens, fixing *this* bug, fixes the other bug.
This produces fully (bit-by-bit) identical state_assembly_test.s
The filecheck change is actually needed regardless of this patch,
else this test does not pass for me even without this diff.
2019-05-13 17:33:11 +08:00
|
|
|
const internal::ThreadManager::Result& results,
|
|
|
|
IterationCount memory_iterations,
|
2021-10-18 23:29:35 +08:00
|
|
|
const MemoryManager::Result* memory_result, double seconds,
|
2021-06-02 17:34:00 +08:00
|
|
|
int64_t repetition_index, int64_t repeats) {
|
2018-10-01 22:51:08 +08:00
|
|
|
// Create report about this benchmark run.
|
|
|
|
BenchmarkReporter::Run report;
|
|
|
|
|
2021-05-11 00:12:09 +08:00
|
|
|
report.run_name = b.name();
|
2021-06-02 23:06:45 +08:00
|
|
|
report.family_index = b.family_index();
|
2021-06-03 04:45:41 +08:00
|
|
|
report.per_family_instance_index = b.per_family_instance_index();
|
2018-10-01 22:51:08 +08:00
|
|
|
report.error_occurred = results.has_error_;
|
|
|
|
report.error_message = results.error_message_;
|
|
|
|
report.report_label = results.report_label_;
|
|
|
|
// This is the total iterations across all threads.
|
|
|
|
report.iterations = results.iterations;
|
2021-05-11 00:12:09 +08:00
|
|
|
report.time_unit = b.time_unit();
|
|
|
|
report.threads = b.threads();
|
2019-03-26 17:53:07 +08:00
|
|
|
report.repetition_index = repetition_index;
|
2021-06-02 17:34:00 +08:00
|
|
|
report.repetitions = repeats;
|
2018-10-01 22:51:08 +08:00
|
|
|
|
|
|
|
if (!report.error_occurred) {
|
2021-05-11 00:12:09 +08:00
|
|
|
if (b.use_manual_time()) {
|
2018-10-01 22:51:08 +08:00
|
|
|
report.real_accumulated_time = results.manual_time_used;
|
|
|
|
} else {
|
|
|
|
report.real_accumulated_time = results.real_time_used;
|
|
|
|
}
|
|
|
|
report.cpu_accumulated_time = results.cpu_time_used;
|
|
|
|
report.complexity_n = results.complexity_n;
|
2021-05-11 00:12:09 +08:00
|
|
|
report.complexity = b.complexity();
|
|
|
|
report.complexity_lambda = b.complexity_lambda();
|
|
|
|
report.statistics = &b.statistics();
|
2018-10-01 22:51:08 +08:00
|
|
|
report.counters = results.counters;
|
|
|
|
|
|
|
|
if (memory_iterations > 0) {
|
2021-10-18 23:29:35 +08:00
|
|
|
assert(memory_result != nullptr);
|
|
|
|
report.memory_result = memory_result;
|
2018-10-01 22:51:08 +08:00
|
|
|
report.allocs_per_iter =
|
2021-10-18 23:29:35 +08:00
|
|
|
memory_iterations ? static_cast<double>(memory_result->num_allocs) /
|
2018-10-01 22:51:08 +08:00
|
|
|
memory_iterations
|
|
|
|
: 0;
|
|
|
|
}
|
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
internal::Finish(&report.counters, results.iterations, seconds,
|
|
|
|
b.threads());
|
2018-10-01 22:51:08 +08:00
|
|
|
}
|
|
|
|
return report;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Execute one thread of benchmark b for the specified number of iterations.
|
Use fewer ramp up repetitions when KeepRunningBatch is used (#1113)
Use the benchmark's reported iteration count when estimating
iterations for the next repetition, rather than the requested
iteration count. When the benchmark uses KeepRunningBatch the actual
iteration count can be larger than the one the runner requested.
Prior to this fix the runner was underestimating the next iteration
count, sometimes significantly so. Consider the case of a benchmark
using a batch size of 1024. Prior to this change, the benchmark
runner would attempt iteration counts 1, 10, 100 and 1000, yet the
benchmark itself would do the same amount of work each time: a single
batch of 1024 iterations. The discrepancy could also contribute to
estimation errors once the benchmark time reached 10% of the target.
For example, if the very first batch of 1024 iterations reached 10% of
benchmark_min_min time, the runner would attempt to scale that to 100%
from a basis of one iteration rather than 1024.
This bug was particularly noticeable in benchmarks with large batch
sizes, especially when the benchmark also had slow set up or tear down
phases.
With this fix in place it is possible to use KeepRunningBatch to
achieve a kind of "minimum iteration count" feature by using a larger
fixed batch size. For example, a benchmark may build a map of 500K
elements and test a "find" operation. There is no point in running
"find" just 1, 10, 100, etc., times. The benchmark can now pick a
batch size of something like 10K, and the runner will arrive at the
final max iteration count with in noticeably fewer repetitions.
2021-04-20 14:16:05 +08:00
|
|
|
// Adds the stats collected for the thread into manager->results.
|
Iteration counts should be `uint64_t` globally. (#817)
This is a shameless rip-off of https://github.com/google/benchmark/pull/646
I did promise to look into why that proposed PR was producing
so much worse assembly, and so i finally did.
The reason is - that diff changes `size_t` (unsigned) to `int64_t` (signed).
There is this nice little `assert`:
https://github.com/google/benchmark/blob/7a1c37028359ca9d386d719a6ad527743cf1b753/include/benchmark/benchmark.h#L744
It ensures that we didn't magically decide to advance our iterator
when we should have finished benchmarking.
When `cached_` was unsigned, the `assert` was `cached_ UGT 0`.
But we only ever get to that `assert` if `cached_ NE 0`,
and naturally if `cached_` is not `0`, then it is bigger than `0`,
so the `assert` is tautological, and gets folded away.
But now that `cached_` became signed, the assert became `cached_ SGT 0`.
And we still only know that `cached_ NE 0`, so the assert can't be
optimized out, or at least it doesn't currently.
Regardless of whether or not that is a bug in itself,
that particular diff would have regressed the normal 64-bit systems,
by halving the maximal iteration space (since we go from unsigned counter
to signed one, of the same bit-width), which seems like a bug.
And just so it happens, fixing *this* bug, fixes the other bug.
This produces fully (bit-by-bit) identical state_assembly_test.s
The filecheck change is actually needed regardless of this patch,
else this test does not pass for me even without this diff.
2019-05-13 17:33:11 +08:00
|
|
|
void RunInThread(const BenchmarkInstance* b, IterationCount iters,
|
2021-04-28 16:25:29 +08:00
|
|
|
int thread_id, ThreadManager* manager,
|
|
|
|
PerfCountersMeasurement* perf_counters_measurement) {
|
2019-04-09 20:01:33 +08:00
|
|
|
internal::ThreadTimer timer(
|
2021-05-11 00:12:09 +08:00
|
|
|
b->measure_process_cpu_time()
|
2019-04-09 20:01:33 +08:00
|
|
|
? internal::ThreadTimer::CreateProcessCpuTime()
|
|
|
|
: internal::ThreadTimer::Create());
|
2022-05-23 20:50:17 +08:00
|
|
|
|
2021-04-28 16:25:29 +08:00
|
|
|
State st =
|
|
|
|
b->Run(iters, thread_id, &timer, manager, perf_counters_measurement);
|
2021-06-25 01:21:59 +08:00
|
|
|
BM_CHECK(st.error_occurred() || st.iterations() >= st.max_iterations)
|
2018-10-01 22:51:08 +08:00
|
|
|
<< "Benchmark returned before State::KeepRunning() returned false!";
|
|
|
|
{
|
|
|
|
MutexLock l(manager->GetBenchmarkMutex());
|
|
|
|
internal::ThreadManager::Result& results = manager->results;
|
|
|
|
results.iterations += st.iterations();
|
|
|
|
results.cpu_time_used += timer.cpu_time_used();
|
|
|
|
results.real_time_used += timer.real_time_used();
|
|
|
|
results.manual_time_used += timer.manual_time_used();
|
|
|
|
results.complexity_n += st.complexity_length_n();
|
|
|
|
internal::Increment(&results.counters, st.counters);
|
|
|
|
}
|
|
|
|
manager->NotifyThreadComplete();
|
|
|
|
}
|
|
|
|
|
2023-02-07 19:45:18 +08:00
|
|
|
double ComputeMinTime(const benchmark::internal::BenchmarkInstance& b,
|
|
|
|
const BenchTimeType& iters_or_time) {
|
|
|
|
if (!IsZero(b.min_time())) return b.min_time();
|
|
|
|
// If the flag was used to specify number of iters, then return the default
|
|
|
|
// min_time.
|
|
|
|
if (iters_or_time.tag == BenchTimeType::ITERS) return kDefaultMinTime;
|
|
|
|
|
|
|
|
return iters_or_time.time;
|
|
|
|
}
|
|
|
|
|
|
|
|
IterationCount ComputeIters(const benchmark::internal::BenchmarkInstance& b,
|
|
|
|
const BenchTimeType& iters_or_time) {
|
|
|
|
if (b.iterations() != 0) return b.iterations();
|
|
|
|
|
|
|
|
// We've already concluded that this flag is currently used to pass
|
|
|
|
// iters but do a check here again anyway.
|
|
|
|
BM_CHECK(iters_or_time.tag == BenchTimeType::ITERS);
|
|
|
|
return iters_or_time.iters;
|
|
|
|
}
|
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
} // end namespace
|
|
|
|
|
2023-02-07 19:45:18 +08:00
|
|
|
BenchTimeType ParseBenchMinTime(const std::string& value) {
|
|
|
|
BenchTimeType ret;
|
|
|
|
|
|
|
|
if (value.empty()) {
|
|
|
|
ret.tag = BenchTimeType::TIME;
|
|
|
|
ret.time = 0.0;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (value.back() == 'x') {
|
|
|
|
const char* iters_str = value.c_str();
|
|
|
|
char* p_end;
|
|
|
|
// Reset errno before it's changed by strtol.
|
|
|
|
errno = 0;
|
|
|
|
IterationCount num_iters = std::strtol(iters_str, &p_end, 10);
|
|
|
|
|
|
|
|
// After a valid parse, p_end should have been set to
|
|
|
|
// point to the 'x' suffix.
|
|
|
|
BM_CHECK(errno == 0 && p_end != nullptr && *p_end == 'x')
|
|
|
|
<< "Malformed iters value passed to --benchmark_min_time: `" << value
|
|
|
|
<< "`. Expected --benchmark_min_time=<integer>x.";
|
|
|
|
|
|
|
|
ret.tag = BenchTimeType::ITERS;
|
|
|
|
ret.iters = num_iters;
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
const char* time_str = value.c_str();
|
|
|
|
bool has_suffix = value.back() == 's';
|
|
|
|
if (!has_suffix) {
|
|
|
|
BM_VLOG(0) << "Value passed to --benchmark_min_time should have a suffix. "
|
|
|
|
"Eg., `30s` for 30-seconds.";
|
|
|
|
}
|
|
|
|
|
|
|
|
char* p_end;
|
|
|
|
// Reset errno before it's changed by strtod.
|
|
|
|
errno = 0;
|
|
|
|
double min_time = std::strtod(time_str, &p_end);
|
|
|
|
|
2023-02-17 02:35:21 +08:00
|
|
|
// After a successful parse, p_end should point to the suffix 's',
|
|
|
|
// or the end of the string if the suffix was omitted.
|
2023-02-07 19:45:18 +08:00
|
|
|
BM_CHECK(errno == 0 && p_end != nullptr &&
|
2023-02-17 02:35:21 +08:00
|
|
|
((has_suffix && *p_end == 's') || *p_end == '\0'))
|
2023-02-07 19:45:18 +08:00
|
|
|
<< "Malformed seconds value passed to --benchmark_min_time: `" << value
|
|
|
|
<< "`. Expected --benchmark_min_time=<float>x.";
|
|
|
|
|
|
|
|
ret.tag = BenchTimeType::TIME;
|
|
|
|
ret.time = min_time;
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
BenchmarkRunner::BenchmarkRunner(
|
|
|
|
const benchmark::internal::BenchmarkInstance& b_,
|
2023-03-07 18:27:52 +08:00
|
|
|
PerfCountersMeasurement* pcm_,
|
Random interleaving of benchmark repetitions - the sequel (fixes #1051) (#1163)
Inspired by the original implementation by Hai Huang @haih-g
from https://github.com/google/benchmark/pull/1105.
The original implementation had design deficiencies that
weren't really addressable without redesign, so it was reverted.
In essence, the original implementation consisted of two separateable parts:
* reducing the amount time each repetition is run for, and symmetrically increasing repetition count
* running the repetitions in random order
While it worked fine for the usual case, it broke down when user would specify repetitions
(it would completely ignore that request), or specified per-repetition min time (while it would
still adjust the repetition count, it would not adjust the per-repetition time,
leading to much greater run times)
Here, like i was originally suggesting in the original review, i'm separating the features,
and only dealing with a single one - running repetitions in random order.
Now that the runs/repetitions are no longer in-order, the tooling may wish to sort the output,
and indeed `compare.py` has been updated to do that: #1168.
2021-06-04 02:16:54 +08:00
|
|
|
BenchmarkReporter::PerFamilyRunReports* reports_for_family_)
|
2021-06-03 21:54:06 +08:00
|
|
|
: b(b_),
|
Random interleaving of benchmark repetitions - the sequel (fixes #1051) (#1163)
Inspired by the original implementation by Hai Huang @haih-g
from https://github.com/google/benchmark/pull/1105.
The original implementation had design deficiencies that
weren't really addressable without redesign, so it was reverted.
In essence, the original implementation consisted of two separateable parts:
* reducing the amount time each repetition is run for, and symmetrically increasing repetition count
* running the repetitions in random order
While it worked fine for the usual case, it broke down when user would specify repetitions
(it would completely ignore that request), or specified per-repetition min time (while it would
still adjust the repetition count, it would not adjust the per-repetition time,
leading to much greater run times)
Here, like i was originally suggesting in the original review, i'm separating the features,
and only dealing with a single one - running repetitions in random order.
Now that the runs/repetitions are no longer in-order, the tooling may wish to sort the output,
and indeed `compare.py` has been updated to do that: #1168.
2021-06-04 02:16:54 +08:00
|
|
|
reports_for_family(reports_for_family_),
|
2023-02-07 19:45:18 +08:00
|
|
|
parsed_benchtime_flag(ParseBenchMinTime(FLAGS_benchmark_min_time)),
|
|
|
|
min_time(ComputeMinTime(b_, parsed_benchtime_flag)),
|
2022-05-23 20:50:17 +08:00
|
|
|
min_warmup_time((!IsZero(b.min_time()) && b.min_warmup_time() > 0.0)
|
|
|
|
? b.min_warmup_time()
|
|
|
|
: FLAGS_benchmark_min_warmup_time),
|
|
|
|
warmup_done(!(min_warmup_time > 0.0)),
|
2021-06-03 21:54:06 +08:00
|
|
|
repeats(b.repetitions() != 0 ? b.repetitions()
|
|
|
|
: FLAGS_benchmark_repetitions),
|
2023-02-07 19:45:18 +08:00
|
|
|
has_explicit_iteration_count(b.iterations() != 0 ||
|
|
|
|
parsed_benchtime_flag.tag ==
|
|
|
|
BenchTimeType::ITERS),
|
2021-06-03 21:54:06 +08:00
|
|
|
pool(b.threads() - 1),
|
2023-02-07 19:45:18 +08:00
|
|
|
iters(has_explicit_iteration_count
|
|
|
|
? ComputeIters(b_, parsed_benchtime_flag)
|
|
|
|
: 1),
|
2023-03-07 18:27:52 +08:00
|
|
|
perf_counters_measurement_ptr(pcm_) {
|
2021-06-03 21:54:06 +08:00
|
|
|
run_results.display_report_aggregates_only =
|
|
|
|
(FLAGS_benchmark_report_aggregates_only ||
|
|
|
|
FLAGS_benchmark_display_aggregates_only);
|
|
|
|
run_results.file_report_aggregates_only =
|
|
|
|
FLAGS_benchmark_report_aggregates_only;
|
|
|
|
if (b.aggregation_report_mode() != internal::ARM_Unspecified) {
|
[NFC] BenchmarkRunner: always populate *_report_aggregates_only bools. (#708)
It is better to let the RunBenchmarks(), report() decide
whether to actually *only* output aggregates or not,
depending on whether there are actually aggregates.
It's subtle indeed.
Previously, `BenchmarkRunner()` always said that "if there are no repetitions,
then you should never output only the repetitions". And the `report()` simply assumed
that the `report_aggregates_only` bool it received makes sense, and simply used it.
Now, the logic is the same, but the blame has shifted.
`BenchmarkRunner()` always propagates what those benchmarks would have wanted
to happen wrt the aggregates. And the `report()` lambda has to actually consider
both the `report_aggregates_only` bool, and it's meaningfulness.
To put it in the context of the patch series - if the repetition count was `1`,
but `*_report_aggregates_only` was set to `true`, and we capture each iteration separately,
then we will compute the aggregates, but then output everything, both the iteration,
and aggregates, despite `*_report_aggregates_only` being set to `true`.
2018-10-18 20:08:59 +08:00
|
|
|
run_results.display_report_aggregates_only =
|
2021-06-03 21:54:06 +08:00
|
|
|
(b.aggregation_report_mode() &
|
|
|
|
internal::ARM_DisplayReportAggregatesOnly);
|
[NFC] BenchmarkRunner: always populate *_report_aggregates_only bools. (#708)
It is better to let the RunBenchmarks(), report() decide
whether to actually *only* output aggregates or not,
depending on whether there are actually aggregates.
It's subtle indeed.
Previously, `BenchmarkRunner()` always said that "if there are no repetitions,
then you should never output only the repetitions". And the `report()` simply assumed
that the `report_aggregates_only` bool it received makes sense, and simply used it.
Now, the logic is the same, but the blame has shifted.
`BenchmarkRunner()` always propagates what those benchmarks would have wanted
to happen wrt the aggregates. And the `report()` lambda has to actually consider
both the `report_aggregates_only` bool, and it's meaningfulness.
To put it in the context of the patch series - if the repetition count was `1`,
but `*_report_aggregates_only` was set to `true`, and we capture each iteration separately,
then we will compute the aggregates, but then output everything, both the iteration,
and aggregates, despite `*_report_aggregates_only` being set to `true`.
2018-10-18 20:08:59 +08:00
|
|
|
run_results.file_report_aggregates_only =
|
2021-06-03 21:54:06 +08:00
|
|
|
(b.aggregation_report_mode() & internal::ARM_FileReportAggregatesOnly);
|
2021-06-25 01:21:59 +08:00
|
|
|
BM_CHECK(FLAGS_benchmark_perf_counters.empty() ||
|
2023-03-07 18:27:52 +08:00
|
|
|
(perf_counters_measurement_ptr->num_counters() == 0))
|
2021-06-03 21:54:06 +08:00
|
|
|
<< "Perf counters were requested but could not be set up.";
|
2018-10-01 22:51:08 +08:00
|
|
|
}
|
2021-06-03 21:54:06 +08:00
|
|
|
}
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
BenchmarkRunner::IterationResults BenchmarkRunner::DoNIterations() {
|
2021-06-25 01:55:37 +08:00
|
|
|
BM_VLOG(2) << "Running " << b.name().str() << " for " << iters << "\n";
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
std::unique_ptr<internal::ThreadManager> manager;
|
|
|
|
manager.reset(new internal::ThreadManager(b.threads()));
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
// Run all but one thread in separate threads
|
|
|
|
for (std::size_t ti = 0; ti < pool.size(); ++ti) {
|
|
|
|
pool[ti] = std::thread(&RunInThread, &b, iters, static_cast<int>(ti + 1),
|
|
|
|
manager.get(), perf_counters_measurement_ptr);
|
|
|
|
}
|
|
|
|
// And run one thread here directly.
|
|
|
|
// (If we were asked to run just one thread, we don't create new threads.)
|
|
|
|
// Yes, we need to do this here *after* we start the separate threads.
|
|
|
|
RunInThread(&b, iters, 0, manager.get(), perf_counters_measurement_ptr);
|
2021-04-28 16:25:29 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
// The main thread has finished. Now let's wait for the other threads.
|
|
|
|
manager->WaitForAllThreads();
|
|
|
|
for (std::thread& thread : pool) thread.join();
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
IterationResults i;
|
|
|
|
// Acquire the measurements/counters from the manager, UNDER THE LOCK!
|
|
|
|
{
|
|
|
|
MutexLock l(manager->GetBenchmarkMutex());
|
|
|
|
i.results = manager->results;
|
|
|
|
}
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
// And get rid of the manager.
|
|
|
|
manager.reset();
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
// Adjust real/manual time stats since they were reported per thread.
|
|
|
|
i.results.real_time_used /= b.threads();
|
|
|
|
i.results.manual_time_used /= b.threads();
|
|
|
|
// If we were measuring whole-process CPU usage, adjust the CPU time too.
|
|
|
|
if (b.measure_process_cpu_time()) i.results.cpu_time_used /= b.threads();
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-25 01:55:37 +08:00
|
|
|
BM_VLOG(2) << "Ran in " << i.results.cpu_time_used << "/"
|
|
|
|
<< i.results.real_time_used << "\n";
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
// By using KeepRunningBatch a benchmark can iterate more times than
|
|
|
|
// requested, so take the iteration count from i.results.
|
|
|
|
i.iters = i.results.iterations / b.threads();
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
// Base decisions off of real time if requested by this benchmark.
|
|
|
|
i.seconds = i.results.cpu_time_used;
|
|
|
|
if (b.use_manual_time()) {
|
|
|
|
i.seconds = i.results.manual_time_used;
|
|
|
|
} else if (b.use_real_time()) {
|
|
|
|
i.seconds = i.results.real_time_used;
|
|
|
|
}
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
return i;
|
|
|
|
}
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
IterationCount BenchmarkRunner::PredictNumItersNeeded(
|
|
|
|
const IterationResults& i) const {
|
|
|
|
// See how much iterations should be increased by.
|
|
|
|
// Note: Avoid division by zero with max(seconds, 1ns).
|
2022-05-23 20:50:17 +08:00
|
|
|
double multiplier = GetMinTimeToApply() * 1.4 / std::max(i.seconds, 1e-9);
|
2021-06-03 21:54:06 +08:00
|
|
|
// If our last run was at least 10% of FLAGS_benchmark_min_time then we
|
|
|
|
// use the multiplier directly.
|
|
|
|
// Otherwise we use at most 10 times expansion.
|
|
|
|
// NOTE: When the last run was at least 10% of the min time the max
|
|
|
|
// expansion should be 14x.
|
2022-05-23 20:50:17 +08:00
|
|
|
const bool is_significant = (i.seconds / GetMinTimeToApply()) > 0.1;
|
2021-07-29 15:59:46 +08:00
|
|
|
multiplier = is_significant ? multiplier : 10.0;
|
2021-06-03 21:54:06 +08:00
|
|
|
|
|
|
|
// So what seems to be the sufficiently-large iteration count? Round up.
|
|
|
|
const IterationCount max_next_iters = static_cast<IterationCount>(
|
|
|
|
std::lround(std::max(multiplier * static_cast<double>(i.iters),
|
|
|
|
static_cast<double>(i.iters) + 1.0)));
|
2022-03-18 23:59:31 +08:00
|
|
|
// But we do have *some* limits though..
|
2021-06-03 21:54:06 +08:00
|
|
|
const IterationCount next_iters = std::min(max_next_iters, kMaxIterations);
|
|
|
|
|
2021-06-25 01:55:37 +08:00
|
|
|
BM_VLOG(3) << "Next iters: " << next_iters << ", " << multiplier << "\n";
|
2021-06-03 21:54:06 +08:00
|
|
|
return next_iters; // round up before conversion to integer.
|
|
|
|
}
|
Use fewer ramp up repetitions when KeepRunningBatch is used (#1113)
Use the benchmark's reported iteration count when estimating
iterations for the next repetition, rather than the requested
iteration count. When the benchmark uses KeepRunningBatch the actual
iteration count can be larger than the one the runner requested.
Prior to this fix the runner was underestimating the next iteration
count, sometimes significantly so. Consider the case of a benchmark
using a batch size of 1024. Prior to this change, the benchmark
runner would attempt iteration counts 1, 10, 100 and 1000, yet the
benchmark itself would do the same amount of work each time: a single
batch of 1024 iterations. The discrepancy could also contribute to
estimation errors once the benchmark time reached 10% of the target.
For example, if the very first batch of 1024 iterations reached 10% of
benchmark_min_min time, the runner would attempt to scale that to 100%
from a basis of one iteration rather than 1024.
This bug was particularly noticeable in benchmarks with large batch
sizes, especially when the benchmark also had slow set up or tear down
phases.
With this fix in place it is possible to use KeepRunningBatch to
achieve a kind of "minimum iteration count" feature by using a larger
fixed batch size. For example, a benchmark may build a map of 500K
elements and test a "find" operation. There is no point in running
"find" just 1, 10, 100, etc., times. The benchmark can now pick a
batch size of something like 10K, and the runner will arrive at the
final max iteration count with in noticeably fewer repetitions.
2021-04-20 14:16:05 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
bool BenchmarkRunner::ShouldReportIterationResults(
|
|
|
|
const IterationResults& i) const {
|
|
|
|
// Determine if this run should be reported;
|
|
|
|
// Either it has run for a sufficient amount of time
|
|
|
|
// or because an error was reported.
|
|
|
|
return i.results.has_error_ ||
|
|
|
|
i.iters >= kMaxIterations || // Too many iterations already.
|
2022-05-23 20:50:17 +08:00
|
|
|
i.seconds >=
|
|
|
|
GetMinTimeToApply() || // The elapsed time is large enough.
|
2021-06-03 21:54:06 +08:00
|
|
|
// CPU time is specified but the elapsed real time greatly exceeds
|
|
|
|
// the minimum time.
|
2022-03-18 23:59:31 +08:00
|
|
|
// Note that user provided timers are except from this test.
|
2022-05-23 20:50:17 +08:00
|
|
|
((i.results.real_time_used >= 5 * GetMinTimeToApply()) &&
|
|
|
|
!b.use_manual_time());
|
|
|
|
}
|
|
|
|
|
|
|
|
double BenchmarkRunner::GetMinTimeToApply() const {
|
|
|
|
// In order to re-use functionality to run and measure benchmarks for running
|
|
|
|
// a warmup phase of the benchmark, we need a way of telling whether to apply
|
|
|
|
// min_time or min_warmup_time. This function will figure out if we are in the
|
|
|
|
// warmup phase and therefore need to apply min_warmup_time or if we already
|
|
|
|
// in the benchmarking phase and min_time needs to be applied.
|
|
|
|
return warmup_done ? min_time : min_warmup_time;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BenchmarkRunner::FinishWarmUp(const IterationCount& i) {
|
|
|
|
warmup_done = true;
|
|
|
|
iters = i;
|
|
|
|
}
|
|
|
|
|
|
|
|
void BenchmarkRunner::RunWarmUp() {
|
|
|
|
// Use the same mechanisms for warming up the benchmark as used for actually
|
|
|
|
// running and measuring the benchmark.
|
|
|
|
IterationResults i_warmup;
|
|
|
|
// Dont use the iterations determined in the warmup phase for the actual
|
|
|
|
// measured benchmark phase. While this may be a good starting point for the
|
|
|
|
// benchmark and it would therefore get rid of the need to figure out how many
|
|
|
|
// iterations are needed if min_time is set again, this may also be a complete
|
|
|
|
// wrong guess since the warmup loops might be considerably slower (e.g
|
|
|
|
// because of caching effects).
|
|
|
|
const IterationCount i_backup = iters;
|
|
|
|
|
|
|
|
for (;;) {
|
|
|
|
b.Setup();
|
|
|
|
i_warmup = DoNIterations();
|
|
|
|
b.Teardown();
|
|
|
|
|
|
|
|
const bool finish = ShouldReportIterationResults(i_warmup);
|
|
|
|
|
|
|
|
if (finish) {
|
|
|
|
FinishWarmUp(i_backup);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Although we are running "only" a warmup phase where running enough
|
|
|
|
// iterations at once without measuring time isn't as important as it is for
|
|
|
|
// the benchmarking phase, we still do it the same way as otherwise it is
|
|
|
|
// very confusing for the user to know how to choose a proper value for
|
|
|
|
// min_warmup_time if a different approach on running it is used.
|
|
|
|
iters = PredictNumItersNeeded(i_warmup);
|
|
|
|
assert(iters > i_warmup.iters &&
|
|
|
|
"if we did more iterations than we want to do the next time, "
|
|
|
|
"then we should have accepted the current iteration run.");
|
|
|
|
}
|
2021-06-03 21:54:06 +08:00
|
|
|
}
|
2018-10-01 22:51:08 +08:00
|
|
|
|
Random interleaving of benchmark repetitions - the sequel (fixes #1051) (#1163)
Inspired by the original implementation by Hai Huang @haih-g
from https://github.com/google/benchmark/pull/1105.
The original implementation had design deficiencies that
weren't really addressable without redesign, so it was reverted.
In essence, the original implementation consisted of two separateable parts:
* reducing the amount time each repetition is run for, and symmetrically increasing repetition count
* running the repetitions in random order
While it worked fine for the usual case, it broke down when user would specify repetitions
(it would completely ignore that request), or specified per-repetition min time (while it would
still adjust the repetition count, it would not adjust the per-repetition time,
leading to much greater run times)
Here, like i was originally suggesting in the original review, i'm separating the features,
and only dealing with a single one - running repetitions in random order.
Now that the runs/repetitions are no longer in-order, the tooling may wish to sort the output,
and indeed `compare.py` has been updated to do that: #1168.
2021-06-04 02:16:54 +08:00
|
|
|
void BenchmarkRunner::DoOneRepetition() {
|
|
|
|
assert(HasRepeatsRemaining() && "Already done all repetitions?");
|
|
|
|
|
|
|
|
const bool is_the_first_repetition = num_repetitions_done == 0;
|
2021-06-03 21:54:06 +08:00
|
|
|
|
2022-05-23 20:50:17 +08:00
|
|
|
// In case a warmup phase is requested by the benchmark, run it now.
|
|
|
|
// After running the warmup phase the BenchmarkRunner should be in a state as
|
|
|
|
// this warmup never happened except the fact that warmup_done is set. Every
|
|
|
|
// other manipulation of the BenchmarkRunner instance would be a bug! Please
|
|
|
|
// fix it.
|
|
|
|
if (!warmup_done) RunWarmUp();
|
|
|
|
|
|
|
|
IterationResults i;
|
2021-06-03 21:54:06 +08:00
|
|
|
// We *may* be gradually increasing the length (iteration count)
|
|
|
|
// of the benchmark until we decide the results are significant.
|
|
|
|
// And once we do, we report those last results and exit.
|
|
|
|
// Please do note that the if there are repetitions, the iteration count
|
|
|
|
// is *only* calculated for the *first* repetition, and other repetitions
|
|
|
|
// simply use that precomputed iteration count.
|
|
|
|
for (;;) {
|
2021-11-18 00:51:55 +08:00
|
|
|
b.Setup();
|
2021-06-03 21:54:06 +08:00
|
|
|
i = DoNIterations();
|
2021-11-18 00:51:55 +08:00
|
|
|
b.Teardown();
|
2021-06-03 21:54:06 +08:00
|
|
|
|
|
|
|
// Do we consider the results to be significant?
|
|
|
|
// If we are doing repetitions, and the first repetition was already done,
|
|
|
|
// it has calculated the correct iteration time, so we have run that very
|
|
|
|
// iteration count just now. No need to calculate anything. Just report.
|
|
|
|
// Else, the normal rules apply.
|
|
|
|
const bool results_are_significant = !is_the_first_repetition ||
|
|
|
|
has_explicit_iteration_count ||
|
|
|
|
ShouldReportIterationResults(i);
|
|
|
|
|
|
|
|
if (results_are_significant) break; // Good, let's report them!
|
|
|
|
|
|
|
|
// Nope, bad iteration. Let's re-estimate the hopefully-sufficient
|
|
|
|
// iteration count, and run the benchmark again...
|
|
|
|
|
|
|
|
iters = PredictNumItersNeeded(i);
|
|
|
|
assert(iters > i.iters &&
|
|
|
|
"if we did more iterations than we want to do the next time, "
|
|
|
|
"then we should have accepted the current iteration run.");
|
2018-10-01 22:51:08 +08:00
|
|
|
}
|
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
// Oh, one last thing, we need to also produce the 'memory measurements'..
|
2021-10-18 23:29:35 +08:00
|
|
|
MemoryManager::Result* memory_result = nullptr;
|
2021-06-03 21:54:06 +08:00
|
|
|
IterationCount memory_iterations = 0;
|
|
|
|
if (memory_manager != nullptr) {
|
2021-10-18 23:29:35 +08:00
|
|
|
// TODO(vyng): Consider making BenchmarkReporter::Run::memory_result an
|
|
|
|
// optional so we don't have to own the Result here.
|
|
|
|
// Can't do it now due to cxx03.
|
|
|
|
memory_results.push_back(MemoryManager::Result());
|
|
|
|
memory_result = &memory_results.back();
|
2021-06-03 21:54:06 +08:00
|
|
|
// Only run a few iterations to reduce the impact of one-time
|
|
|
|
// allocations in benchmarks that are not properly managed.
|
|
|
|
memory_iterations = std::min<IterationCount>(16, iters);
|
|
|
|
memory_manager->Start();
|
|
|
|
std::unique_ptr<internal::ThreadManager> manager;
|
|
|
|
manager.reset(new internal::ThreadManager(1));
|
2021-11-18 00:51:55 +08:00
|
|
|
b.Setup();
|
2021-06-03 21:54:06 +08:00
|
|
|
RunInThread(&b, memory_iterations, 0, manager.get(),
|
|
|
|
perf_counters_measurement_ptr);
|
|
|
|
manager->WaitForAllThreads();
|
|
|
|
manager.reset();
|
2021-11-18 00:51:55 +08:00
|
|
|
b.Teardown();
|
2022-11-11 23:12:12 +08:00
|
|
|
memory_manager->Stop(*memory_result);
|
2018-10-01 22:51:08 +08:00
|
|
|
}
|
|
|
|
|
2021-06-29 00:07:54 +08:00
|
|
|
// Ok, now actually report.
|
2021-06-03 21:54:06 +08:00
|
|
|
BenchmarkReporter::Run report =
|
|
|
|
CreateRunReport(b, i.results, memory_iterations, memory_result, i.seconds,
|
Random interleaving of benchmark repetitions - the sequel (fixes #1051) (#1163)
Inspired by the original implementation by Hai Huang @haih-g
from https://github.com/google/benchmark/pull/1105.
The original implementation had design deficiencies that
weren't really addressable without redesign, so it was reverted.
In essence, the original implementation consisted of two separateable parts:
* reducing the amount time each repetition is run for, and symmetrically increasing repetition count
* running the repetitions in random order
While it worked fine for the usual case, it broke down when user would specify repetitions
(it would completely ignore that request), or specified per-repetition min time (while it would
still adjust the repetition count, it would not adjust the per-repetition time,
leading to much greater run times)
Here, like i was originally suggesting in the original review, i'm separating the features,
and only dealing with a single one - running repetitions in random order.
Now that the runs/repetitions are no longer in-order, the tooling may wish to sort the output,
and indeed `compare.py` has been updated to do that: #1168.
2021-06-04 02:16:54 +08:00
|
|
|
num_repetitions_done, repeats);
|
2018-10-01 22:51:08 +08:00
|
|
|
|
Random interleaving of benchmark repetitions - the sequel (fixes #1051) (#1163)
Inspired by the original implementation by Hai Huang @haih-g
from https://github.com/google/benchmark/pull/1105.
The original implementation had design deficiencies that
weren't really addressable without redesign, so it was reverted.
In essence, the original implementation consisted of two separateable parts:
* reducing the amount time each repetition is run for, and symmetrically increasing repetition count
* running the repetitions in random order
While it worked fine for the usual case, it broke down when user would specify repetitions
(it would completely ignore that request), or specified per-repetition min time (while it would
still adjust the repetition count, it would not adjust the per-repetition time,
leading to much greater run times)
Here, like i was originally suggesting in the original review, i'm separating the features,
and only dealing with a single one - running repetitions in random order.
Now that the runs/repetitions are no longer in-order, the tooling may wish to sort the output,
and indeed `compare.py` has been updated to do that: #1168.
2021-06-04 02:16:54 +08:00
|
|
|
if (reports_for_family) {
|
|
|
|
++reports_for_family->num_runs_done;
|
|
|
|
if (!report.error_occurred) reports_for_family->Runs.push_back(report);
|
|
|
|
}
|
2018-10-01 22:51:08 +08:00
|
|
|
|
2021-06-03 21:54:06 +08:00
|
|
|
run_results.non_aggregates.push_back(report);
|
Random interleaving of benchmark repetitions - the sequel (fixes #1051) (#1163)
Inspired by the original implementation by Hai Huang @haih-g
from https://github.com/google/benchmark/pull/1105.
The original implementation had design deficiencies that
weren't really addressable without redesign, so it was reverted.
In essence, the original implementation consisted of two separateable parts:
* reducing the amount time each repetition is run for, and symmetrically increasing repetition count
* running the repetitions in random order
While it worked fine for the usual case, it broke down when user would specify repetitions
(it would completely ignore that request), or specified per-repetition min time (while it would
still adjust the repetition count, it would not adjust the per-repetition time,
leading to much greater run times)
Here, like i was originally suggesting in the original review, i'm separating the features,
and only dealing with a single one - running repetitions in random order.
Now that the runs/repetitions are no longer in-order, the tooling may wish to sort the output,
and indeed `compare.py` has been updated to do that: #1168.
2021-06-04 02:16:54 +08:00
|
|
|
|
|
|
|
++num_repetitions_done;
|
2021-06-03 21:54:06 +08:00
|
|
|
}
|
2018-10-01 22:51:08 +08:00
|
|
|
|
Random interleaving of benchmark repetitions - the sequel (fixes #1051) (#1163)
Inspired by the original implementation by Hai Huang @haih-g
from https://github.com/google/benchmark/pull/1105.
The original implementation had design deficiencies that
weren't really addressable without redesign, so it was reverted.
In essence, the original implementation consisted of two separateable parts:
* reducing the amount time each repetition is run for, and symmetrically increasing repetition count
* running the repetitions in random order
While it worked fine for the usual case, it broke down when user would specify repetitions
(it would completely ignore that request), or specified per-repetition min time (while it would
still adjust the repetition count, it would not adjust the per-repetition time,
leading to much greater run times)
Here, like i was originally suggesting in the original review, i'm separating the features,
and only dealing with a single one - running repetitions in random order.
Now that the runs/repetitions are no longer in-order, the tooling may wish to sort the output,
and indeed `compare.py` has been updated to do that: #1168.
2021-06-04 02:16:54 +08:00
|
|
|
RunResults&& BenchmarkRunner::GetResults() {
|
|
|
|
assert(!HasRepeatsRemaining() && "Did not run all repetitions yet?");
|
|
|
|
|
|
|
|
// Calculate additional statistics over the repetitions of this instance.
|
|
|
|
run_results.aggregates_only = ComputeStats(run_results.non_aggregates);
|
|
|
|
|
|
|
|
return std::move(run_results);
|
2018-10-01 22:51:08 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
} // end namespace internal
|
|
|
|
|
|
|
|
} // end namespace benchmark
|