benchmark/test/benchmark_test.cc

246 lines
7.1 KiB
C++
Raw Normal View History

#include "benchmark/benchmark.h"
#include <assert.h>
#include <math.h>
#include <stdint.h>
#include <chrono>
2015-10-08 09:43:45 +00:00
#include <cstdlib>
2014-01-07 21:14:41 +00:00
#include <iostream>
#include <limits>
#include <list>
#include <map>
2014-08-04 10:38:37 +00:00
#include <mutex>
#include <set>
#include <sstream>
#include <string>
2016-04-30 13:23:58 +00:00
#include <thread>
#include <utility>
#include <vector>
#if defined(__GNUC__)
#define BENCHMARK_NOINLINE __attribute__((noinline))
#else
#define BENCHMARK_NOINLINE
#endif
namespace {
int BENCHMARK_NOINLINE Factorial(uint32_t n) {
return (n == 1) ? 1 : n * Factorial(n - 1);
}
double CalculatePi(int depth) {
double pi = 0.0;
for (int i = 0; i < depth; ++i) {
double numerator = static_cast<double>(((i % 2) * 2) - 1);
double denominator = static_cast<double>((2 * i) - 1);
pi += numerator / denominator;
}
return (pi - 1.0) * 4;
}
std::set<int64_t> ConstructRandomSet(int64_t size) {
std::set<int64_t> s;
for (int i = 0; i < size; ++i) s.insert(s.end(), i);
return s;
}
2014-08-04 10:38:37 +00:00
std::mutex test_vector_mu;
2014-01-07 21:14:41 +00:00
std::vector<int>* test_vector = nullptr;
} // end namespace
static void BM_Factorial(benchmark::State& state) {
int fac_42 = 0;
for (auto _ : state) fac_42 = Factorial(8);
// Prevent compiler optimizations
std::stringstream ss;
ss << fac_42;
state.SetLabel(ss.str());
}
BENCHMARK(BM_Factorial);
BENCHMARK(BM_Factorial)->UseRealTime();
static void BM_CalculatePiRange(benchmark::State& state) {
double pi = 0.0;
for (auto _ : state) pi = CalculatePi(static_cast<int>(state.range(0)));
std::stringstream ss;
ss << pi;
state.SetLabel(ss.str());
}
BENCHMARK_RANGE(BM_CalculatePiRange, 1, 1024 * 1024);
2014-01-07 21:14:41 +00:00
static void BM_CalculatePi(benchmark::State& state) {
static const int depth = 1024;
for (auto _ : state) {
benchmark::DoNotOptimize(CalculatePi(static_cast<int>(depth)));
}
}
BENCHMARK(BM_CalculatePi)->Threads(8);
BENCHMARK(BM_CalculatePi)->ThreadRange(1, 32);
BENCHMARK(BM_CalculatePi)->ThreadPerCpu();
2014-01-07 21:14:41 +00:00
static void BM_SetInsert(benchmark::State& state) {
std::set<int64_t> data;
for (auto _ : state) {
state.PauseTiming();
data = ConstructRandomSet(state.range(0));
state.ResumeTiming();
for (int j = 0; j < state.range(1); ++j) data.insert(rand());
}
state.SetItemsProcessed(state.iterations() * state.range(1));
state.SetBytesProcessed(state.iterations() * state.range(1) * sizeof(int));
}
// Test many inserts at once to reduce the total iterations needed. Otherwise, the slower,
// non-timed part of each iteration will make the benchmark take forever.
BENCHMARK(BM_SetInsert)->Ranges({{1 << 10, 8 << 10}, {128, 512}});
template <typename Container,
typename ValueType = typename Container::value_type>
static void BM_Sequential(benchmark::State& state) {
ValueType v = 42;
for (auto _ : state) {
Container c;
for (int64_t i = state.range(0); --i;) c.push_back(v);
}
const int64_t items_processed = state.iterations() * state.range(0);
state.SetItemsProcessed(items_processed);
state.SetBytesProcessed(items_processed * sizeof(v));
}
BENCHMARK_TEMPLATE2(BM_Sequential, std::vector<int>, int)
->Range(1 << 0, 1 << 10);
BENCHMARK_TEMPLATE(BM_Sequential, std::list<int>)->Range(1 << 0, 1 << 10);
2015-03-18 20:34:43 +00:00
// Test the variadic version of BENCHMARK_TEMPLATE in C++11 and beyond.
#ifdef BENCHMARK_HAS_CXX11
2015-03-18 20:34:43 +00:00
BENCHMARK_TEMPLATE(BM_Sequential, std::vector<int>, int)->Arg(512);
#endif
static void BM_StringCompare(benchmark::State& state) {
size_t len = static_cast<size_t>(state.range(0));
std::string s1(len, '-');
std::string s2(len, '-');
for (auto _ : state) benchmark::DoNotOptimize(s1.compare(s2));
}
BENCHMARK(BM_StringCompare)->Range(1, 1 << 20);
static void BM_SetupTeardown(benchmark::State& state) {
Introduce accessors for currently public data members (threads and thread_index) (#1208) * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else.
2021-08-23 08:06:57 +00:00
if (state.thread_index() == 0) {
2014-01-07 21:14:41 +00:00
// No need to lock test_vector_mu here as this is running single-threaded.
test_vector = new std::vector<int>();
2014-01-07 21:14:41 +00:00
}
int i = 0;
for (auto _ : state) {
2014-08-04 10:38:37 +00:00
std::lock_guard<std::mutex> l(test_vector_mu);
if (i % 2 == 0)
2014-01-07 21:14:41 +00:00
test_vector->push_back(i);
else
test_vector->pop_back();
++i;
}
Introduce accessors for currently public data members (threads and thread_index) (#1208) * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else.
2021-08-23 08:06:57 +00:00
if (state.thread_index() == 0) {
delete test_vector;
}
}
2014-01-07 21:14:41 +00:00
BENCHMARK(BM_SetupTeardown)->ThreadPerCpu();
static void BM_LongTest(benchmark::State& state) {
double tracker = 0.0;
for (auto _ : state) {
for (int i = 0; i < state.range(0); ++i)
benchmark::DoNotOptimize(tracker += i);
}
}
BENCHMARK(BM_LongTest)->Range(1 << 16, 1 << 28);
static void BM_ParallelMemset(benchmark::State& state) {
int64_t size = state.range(0) / static_cast<int64_t>(sizeof(int));
Introduce accessors for currently public data members (threads and thread_index) (#1208) * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else.
2021-08-23 08:06:57 +00:00
int thread_size = static_cast<int>(size) / state.threads();
int from = thread_size * state.thread_index();
int to = from + thread_size;
Introduce accessors for currently public data members (threads and thread_index) (#1208) * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else.
2021-08-23 08:06:57 +00:00
if (state.thread_index() == 0) {
test_vector = new std::vector<int>(static_cast<size_t>(size));
}
for (auto _ : state) {
for (int i = from; i < to; i++) {
// No need to lock test_vector_mu as ranges
// do not overlap between threads.
benchmark::DoNotOptimize(test_vector->at(i) = 1);
}
}
Introduce accessors for currently public data members (threads and thread_index) (#1208) * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else.
2021-08-23 08:06:57 +00:00
if (state.thread_index() == 0) {
delete test_vector;
}
}
BENCHMARK(BM_ParallelMemset)->Arg(10 << 20)->ThreadRange(1, 4);
2016-04-30 13:23:58 +00:00
static void BM_ManualTiming(benchmark::State& state) {
int64_t slept_for = 0;
int64_t microseconds = state.range(0);
std::chrono::duration<double, std::micro> sleep_duration{
static_cast<double>(microseconds)};
2016-04-30 13:23:58 +00:00
for (auto _ : state) {
auto start = std::chrono::high_resolution_clock::now();
// Simulate some useful workload with a sleep
std::this_thread::sleep_for(
std::chrono::duration_cast<std::chrono::nanoseconds>(sleep_duration));
auto end = std::chrono::high_resolution_clock::now();
2016-04-30 13:23:58 +00:00
auto elapsed =
std::chrono::duration_cast<std::chrono::duration<double>>(end - start);
2016-04-30 13:23:58 +00:00
state.SetIterationTime(elapsed.count());
slept_for += microseconds;
}
state.SetItemsProcessed(slept_for);
}
BENCHMARK(BM_ManualTiming)->Range(1, 1 << 14)->UseRealTime();
BENCHMARK(BM_ManualTiming)->Range(1, 1 << 14)->UseManualTime();
#ifdef BENCHMARK_HAS_CXX11
template <class... Args>
void BM_with_args(benchmark::State& state, Args&&...) {
for (auto _ : state) {
}
}
BENCHMARK_CAPTURE(BM_with_args, int_test, 42, 43, 44);
BENCHMARK_CAPTURE(BM_with_args, string_and_pair_test, std::string("abc"),
std::pair<int, double>(42, 3.8));
void BM_non_template_args(benchmark::State& state, int, double) {
Add user-defined counters. (#262) * Added user counters, and move use of bytes_processed and items_processed to user counter logic. Each counter is a string-value pair. The counters were made available through the State class. Two helper virtual methods were added to the Fixture class to allow convenient initialization and termination of the counters: InitState() and TerminateState(). The reporting of the counters is buggy and is still a work in progress, to be completed in the next commits. * fix bad removal of BenchmarkCounters code during the merge * add myself to AUTHORS/CONTRIBUTORS * fix printing to std::cout in csv_reporter * bytes_per_second and items_per_second are now in the UserCounters class * add user counters to json reporter * moving bytes_per_second and items_per_second to their old state * console reporter dealing ok with user counters. * update unit tests for user counters * CSVReporter now prints user counters too. * cleanup user counters * reverted changes to cmake files which should have gone into later commits * fixture_test: fix gcc 4.6 compilation * remove ctor with default argument see https://github.com/google/benchmark/pull/262#discussion_r72298055 * use (auto-defined) BENCHMARK_HAS_CXX11 instead of BENCHMARK_INITLIST. https://github.com/google/benchmark/pull/262#discussion_r72298310 * leanify counters API Discussions: API complexity: https://github.com/google/benchmark/pull/262#discussion_r72298731 remove std::string dependency (WIP): https://github.com/google/benchmark/pull/262#discussion_r72298142 spacing & alignment: https://github.com/google/benchmark/pull/262#discussion_r72298422 * remove std::string dependency on public API - changed counter name storage to char* * Counter ctor: use overloads instead of default arguments discussion: https://github.com/google/benchmark/pull/262#discussion_r72298055 * Use raw pointers to remove dependency on std::vector from public API . For more info, see discussion at https://github.com/google/benchmark/pull/262#discussion_r72319678 . * Move counter implementation from benchmark.cc to counter.cc. See discussion: https://github.com/google/benchmark/pull/262#discussion_r72298980 . * Remove unused (commented-out) code. * Moved thread counters to ThreadStats. * Counters: fixed copy and move constructors. * Counter: use an inplace buffer for small names. * benchmark_test: move counters test out of CXX11 preprocessor conditional. * Counter: fix VS2013 compilation error in char[] initialization. * Fix typo. * Expose counters from State. See discussion: https://github.com/google/benchmark/pull/262#issuecomment-237156951 * Changed counters interface to map-like. * Fix printing of user counters in ConsoleReporter. * Applied clang-format to counter.cc and console_reporter.cc. Command was `clang-format -style=Google -i counter.cc console_reporter.cc` I also applied to all other files, but the changes were very far-reaching so I rolled those back. * Rename Counter::Flags_e to Counter::Flags * Fix use of reserved names in Counter and BenchmarkCounters. * Counter: Fix move ctor bug + change order of members. * Fixture: remove tentative methods InitState() and TerminateState(). * Update fixture_test to the new Fixture interface. * BenchmarkCounters: fixed a bug in the move ctor. Remove call to CHECK_LT(). CHECK_LT() was making the size_t lookup take ~double the time of a string lookup! * BenchmarkCounters: add option to not print zero counters (defaults to false). * Add test to compare counter storage and access with std::map. * README: clarify cost of counter access modes. * move counter access test to an own test. * BenchmarkCounters: add move Insert() * Counters access test: add accelerated lookup by name. * Fix old range syntax. * Fix missing include of cstdio * Fix Visual Studio warning * VS2013 and lower: fix use of snprintf() * VS2013: fix use of char[] as a member of std::pair<>. * change counter storage to std::map * Remove skipZeroCounters logic * Fix VS compilation error. * Implemented request changes to PR #262. * PR #262: More requested changes. * README: cleanup counter text. * PR #262: remove clang-format changes for preexisting code * Complexity+Counters: fix counter flags which were being ignored. * Document all Counter::Flag members * fixed loss of counter values * ConsoleReporter: remove tabular printing of user counters. * ConsoleReporter: header printing should not be contingent on user counter names. * Minor white space and alignment fixes. * cxx03_test + counters: reuse the BM_empty() function. * user counters: add note to README on how counters are gathered across threads
2017-03-02 00:23:42 +00:00
while(state.KeepRunning()) {}
}
BENCHMARK_CAPTURE(BM_non_template_args, basic_test, 0, 0);
#endif // BENCHMARK_HAS_CXX11
static void BM_DenseThreadRanges(benchmark::State& st) {
switch (st.range(0)) {
case 1:
Introduce accessors for currently public data members (threads and thread_index) (#1208) * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else.
2021-08-23 08:06:57 +00:00
assert(st.threads() == 1 || st.threads() == 2 || st.threads() == 3);
break;
case 2:
Introduce accessors for currently public data members (threads and thread_index) (#1208) * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else.
2021-08-23 08:06:57 +00:00
assert(st.threads() == 1 || st.threads() == 3 || st.threads() == 4);
break;
case 3:
Introduce accessors for currently public data members (threads and thread_index) (#1208) * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate the direct access to these fields. Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else. * [benchmark] Introduce accessors for currently public data members `threads` and `thread_index` Also deprecate direct access to `.thread_index` and make threads a private field Motivations: Our internal library provides accessors for those fields because the styleguide disalows accessing classes' data members directly (even if they're const). There has been a discussion to simply move internal library to make its fields public similarly to the OSS version here, however, the concern is that these kinds of direct access would prevent many types of future design changes (eg how/whether the values would be stored in the data member) I think the concensus in the end is that we'd change the external library for this case. AFAIK, there are three important third_party users that we'd need to migrate: tcmalloc, abseil and tensorflow. Please let me know if I'm missing anyone else.
2021-08-23 08:06:57 +00:00
assert(st.threads() == 5 || st.threads() == 8 || st.threads() == 11 ||
st.threads() == 14);
break;
default:
assert(false && "Invalid test case number");
}
while (st.KeepRunning()) {
}
}
BENCHMARK(BM_DenseThreadRanges)->Arg(1)->DenseThreadRange(1, 3);
BENCHMARK(BM_DenseThreadRanges)->Arg(2)->DenseThreadRange(1, 4, 2);
BENCHMARK(BM_DenseThreadRanges)->Arg(3)->DenseThreadRange(5, 14, 3);
BENCHMARK_MAIN();