2015-03-18 12:23:43 +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.
|
|
|
|
|
2017-07-05 06:31:47 +08:00
|
|
|
#include "benchmark/benchmark.h"
|
2016-06-02 05:08:01 +08:00
|
|
|
#include "complexity.h"
|
2015-03-18 12:23:43 +08:00
|
|
|
|
2016-05-25 05:44:58 +08:00
|
|
|
#include <algorithm>
|
2016-06-03 04:01:31 +08:00
|
|
|
#include <cstdint>
|
2015-03-18 12:23:43 +08:00
|
|
|
#include <iostream>
|
|
|
|
#include <string>
|
2016-03-30 15:14:04 +08:00
|
|
|
#include <tuple>
|
2015-03-18 12:23:43 +08:00
|
|
|
#include <vector>
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
#include <iomanip> // for setprecision
|
|
|
|
#include <limits>
|
2015-03-18 12:23:43 +08:00
|
|
|
|
|
|
|
#include "string_util.h"
|
2016-09-03 11:34:34 +08:00
|
|
|
#include "timers.h"
|
2015-03-18 12:23:43 +08:00
|
|
|
|
|
|
|
namespace benchmark {
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
std::string FormatKV(std::string const& key, std::string const& value) {
|
|
|
|
return StringPrintF("\"%s\": \"%s\"", key.c_str(), value.c_str());
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string FormatKV(std::string const& key, const char* value) {
|
|
|
|
return StringPrintF("\"%s\": \"%s\"", key.c_str(), value);
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string FormatKV(std::string const& key, bool value) {
|
|
|
|
return StringPrintF("\"%s\": %s", key.c_str(), value ? "true" : "false");
|
|
|
|
}
|
|
|
|
|
|
|
|
std::string FormatKV(std::string const& key, int64_t value) {
|
|
|
|
std::stringstream ss;
|
|
|
|
ss << '"' << key << "\": " << value;
|
|
|
|
return ss.str();
|
|
|
|
}
|
|
|
|
|
2016-10-08 12:26:01 +08:00
|
|
|
std::string FormatKV(std::string const& key, double value) {
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
std::stringstream ss;
|
|
|
|
ss << '"' << key << "\": ";
|
|
|
|
|
|
|
|
const auto max_digits10 = std::numeric_limits<decltype (value)>::max_digits10;
|
|
|
|
const auto max_fractional_digits10 = max_digits10 - 1;
|
|
|
|
|
|
|
|
ss << std::scientific << std::setprecision(max_fractional_digits10) << value;
|
|
|
|
return ss.str();
|
2016-10-08 12:26:01 +08:00
|
|
|
}
|
|
|
|
|
2016-10-08 02:35:03 +08:00
|
|
|
int64_t RoundDouble(double v) { return static_cast<int64_t>(v + 0.5); }
|
2015-03-18 12:23:43 +08:00
|
|
|
|
2016-10-08 02:35:03 +08:00
|
|
|
} // end namespace
|
2015-03-18 12:23:43 +08:00
|
|
|
|
|
|
|
bool JSONReporter::ReportContext(const Context& context) {
|
2016-05-28 03:34:37 +08:00
|
|
|
std::ostream& out = GetOutputStream();
|
2015-03-18 12:23:43 +08:00
|
|
|
|
|
|
|
out << "{\n";
|
|
|
|
std::string inner_indent(2, ' ');
|
|
|
|
|
|
|
|
// Open context block and print context information.
|
|
|
|
out << inner_indent << "\"context\": {\n";
|
|
|
|
std::string indent(4, ' ');
|
2015-03-27 02:26:07 +08:00
|
|
|
|
|
|
|
std::string walltime_value = LocalDateTimeString();
|
2015-03-18 12:23:43 +08:00
|
|
|
out << indent << FormatKV("date", walltime_value) << ",\n";
|
|
|
|
|
2017-11-23 00:33:52 +08:00
|
|
|
CPUInfo const& info = context.cpu_info;
|
|
|
|
out << indent << FormatKV("num_cpus", static_cast<int64_t>(info.num_cpus))
|
2015-03-18 12:23:43 +08:00
|
|
|
<< ",\n";
|
2017-11-23 00:33:52 +08:00
|
|
|
out << indent
|
|
|
|
<< FormatKV("mhz_per_cpu",
|
|
|
|
RoundDouble(info.cycles_per_second / 1000000.0))
|
2015-03-18 12:23:43 +08:00
|
|
|
<< ",\n";
|
2017-11-23 00:33:52 +08:00
|
|
|
out << indent << FormatKV("cpu_scaling_enabled", info.scaling_enabled)
|
2015-03-18 12:23:43 +08:00
|
|
|
<< ",\n";
|
|
|
|
|
2017-11-27 04:33:01 +08:00
|
|
|
out << indent << "\"caches\": [\n";
|
|
|
|
indent = std::string(6, ' ');
|
|
|
|
std::string cache_indent(8, ' ');
|
|
|
|
for (size_t i = 0; i < info.caches.size(); ++i) {
|
|
|
|
auto& CI = info.caches[i];
|
|
|
|
out << indent << "{\n";
|
|
|
|
out << cache_indent << FormatKV("type", CI.type) << ",\n";
|
|
|
|
out << cache_indent << FormatKV("level", static_cast<int64_t>(CI.level))
|
|
|
|
<< ",\n";
|
|
|
|
out << cache_indent
|
|
|
|
<< FormatKV("size", static_cast<int64_t>(CI.size) * 1000u) << ",\n";
|
|
|
|
out << cache_indent
|
|
|
|
<< FormatKV("num_sharing", static_cast<int64_t>(CI.num_sharing))
|
|
|
|
<< "\n";
|
|
|
|
out << indent << "}";
|
|
|
|
if (i != info.caches.size() - 1) out << ",";
|
|
|
|
out << "\n";
|
|
|
|
}
|
|
|
|
indent = std::string(4, ' ');
|
|
|
|
out << indent << "],\n";
|
|
|
|
|
2015-03-18 12:23:43 +08:00
|
|
|
#if defined(NDEBUG)
|
|
|
|
const char build_type[] = "release";
|
|
|
|
#else
|
|
|
|
const char build_type[] = "debug";
|
|
|
|
#endif
|
2015-04-01 02:40:46 +08:00
|
|
|
out << indent << FormatKV("library_build_type", build_type) << "\n";
|
2015-03-18 12:23:43 +08:00
|
|
|
// Close context block and open the list of benchmarks.
|
|
|
|
out << inner_indent << "},\n";
|
|
|
|
out << inner_indent << "\"benchmarks\": [\n";
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void JSONReporter::ReportRuns(std::vector<Run> const& reports) {
|
|
|
|
if (reports.empty()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
std::string indent(4, ' ');
|
2016-05-28 03:34:37 +08:00
|
|
|
std::ostream& out = GetOutputStream();
|
2015-03-18 12:23:43 +08:00
|
|
|
if (!first_report_) {
|
|
|
|
out << ",\n";
|
|
|
|
}
|
|
|
|
first_report_ = false;
|
2016-05-25 05:44:58 +08:00
|
|
|
|
2016-05-28 06:45:25 +08:00
|
|
|
for (auto it = reports.begin(); it != reports.end(); ++it) {
|
2016-06-03 04:01:31 +08:00
|
|
|
out << indent << "{\n";
|
|
|
|
PrintRunData(*it);
|
|
|
|
out << indent << '}';
|
|
|
|
auto it_cp = it;
|
|
|
|
if (++it_cp != reports.end()) {
|
|
|
|
out << ",\n";
|
|
|
|
}
|
2015-03-18 12:23:43 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void JSONReporter::Finalize() {
|
2016-06-03 04:01:31 +08:00
|
|
|
// Close the list of benchmarks and the top level object.
|
|
|
|
GetOutputStream() << "\n ]\n}\n";
|
2015-03-18 12:23:43 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void JSONReporter::PrintRunData(Run const& run) {
|
2016-06-03 04:01:31 +08:00
|
|
|
std::string indent(6, ' ');
|
|
|
|
std::ostream& out = GetOutputStream();
|
2016-10-08 02:35:03 +08:00
|
|
|
out << indent << FormatKV("name", run.benchmark_name) << ",\n";
|
|
|
|
if (run.error_occurred) {
|
|
|
|
out << indent << FormatKV("error_occurred", run.error_occurred) << ",\n";
|
|
|
|
out << indent << FormatKV("error_message", run.error_message) << ",\n";
|
|
|
|
}
|
|
|
|
if (!run.report_big_o && !run.report_rms) {
|
|
|
|
out << indent << FormatKV("iterations", run.iterations) << ",\n";
|
2015-03-18 12:23:43 +08:00
|
|
|
out << indent
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
<< FormatKV("real_time", run.GetAdjustedRealTime())
|
2015-03-18 12:23:43 +08:00
|
|
|
<< ",\n";
|
2016-10-08 02:35:03 +08:00
|
|
|
out << indent
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
<< FormatKV("cpu_time", run.GetAdjustedCPUTime());
|
2016-10-08 02:35:03 +08:00
|
|
|
out << ",\n"
|
|
|
|
<< indent << FormatKV("time_unit", GetTimeUnitString(run.time_unit));
|
2016-06-03 04:01:31 +08:00
|
|
|
} else if (run.report_big_o) {
|
|
|
|
out << indent
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
<< FormatKV("cpu_coefficient", run.GetAdjustedCPUTime())
|
2016-06-03 04:01:31 +08:00
|
|
|
<< ",\n";
|
|
|
|
out << indent
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
<< FormatKV("real_coefficient", run.GetAdjustedRealTime())
|
2016-06-03 04:01:31 +08:00
|
|
|
<< ",\n";
|
2016-10-08 02:35:03 +08:00
|
|
|
out << indent << FormatKV("big_o", GetBigOString(run.complexity)) << ",\n";
|
|
|
|
out << indent << FormatKV("time_unit", GetTimeUnitString(run.time_unit));
|
|
|
|
} else if (run.report_rms) {
|
2016-06-03 04:01:31 +08:00
|
|
|
out << indent
|
2016-10-08 12:26:01 +08:00
|
|
|
<< FormatKV("rms", run.GetAdjustedCPUTime());
|
2016-06-03 04:01:31 +08:00
|
|
|
}
|
|
|
|
if (run.bytes_per_second > 0.0) {
|
|
|
|
out << ",\n"
|
|
|
|
<< indent
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
<< FormatKV("bytes_per_second", run.bytes_per_second);
|
2016-06-03 04:01:31 +08:00
|
|
|
}
|
|
|
|
if (run.items_per_second > 0.0) {
|
|
|
|
out << ",\n"
|
|
|
|
<< indent
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
<< FormatKV("items_per_second", run.items_per_second);
|
2016-06-03 04:01:31 +08:00
|
|
|
}
|
2017-03-02 08:23:42 +08:00
|
|
|
for(auto &c : run.counters) {
|
|
|
|
out << ",\n"
|
|
|
|
<< indent
|
Json reporter: don't cast floating-point to int; adjust tooling (#426)
* Json reporter: passthrough fp, don't cast it to int; adjust tooling
Json output format is generally meant for further processing
using some automated tools. Thus, it makes sense not to
intentionally limit the precision of the values contained
in the report.
As it can be seen, FormatKV() for doubles, used %.2f format,
which was meant to preserve at least some of the precision.
However, before that function is ever called, the doubles
were already cast to the integer via RoundDouble()...
This is also the case for console reporter, where it makes
sense because the screen space is limited, and this reporter,
however the CSV reporter does output some( decimal digits.
Thus i can only conclude that the loss of the precision
was not really considered, so i have decided to adjust the
code of the json reporter to output the full fp precision.
There can be several reasons why that is the right thing
to do, the bigger the time_unit used, the greater the
precision loss, so i'd say any sort of further processing
(like e.g. tools/compare_bench.py does) is best done
on the values with most precision.
Also, that cast skewed the data away from zero, which
i think may or may not result in false- positives/negatives
in the output of tools/compare_bench.py
* Json reporter: FormatKV(double): address review note
* tools/gbench/report.py: skip benchmarks with different time units
While it may be useful to teach it to operate on the
measurements with different time units, which is now
possible since floats are stored, and not the integers,
but for now at least doing such a sanity-checking
is better than providing misinformation.
2017-07-25 07:13:55 +08:00
|
|
|
<< FormatKV(c.first, c.second);
|
2017-03-02 08:23:42 +08:00
|
|
|
}
|
2016-06-03 04:01:31 +08:00
|
|
|
if (!run.report_label.empty()) {
|
2016-10-08 02:35:03 +08:00
|
|
|
out << ",\n" << indent << FormatKV("label", run.report_label);
|
2016-06-03 04:01:31 +08:00
|
|
|
}
|
|
|
|
out << '\n';
|
2015-03-18 12:23:43 +08:00
|
|
|
}
|
|
|
|
|
2017-03-02 08:23:42 +08:00
|
|
|
} // end namespace benchmark
|