Repository files navigation

This repository contains a set of relatively small programs (usually based ongbenchmark micro benchmarking infrastructure) built on top ofROOT. Their primary goal is to provide stable performance metrics which can be monitored over time.

Results of nightly run of ROOT benchmarks could be discovered in the Rootbench.git Grafana instance:RootBench Grafana.

Linux/OSX	Experimental Benchmark Coverage:

@inproceedings{shadura2019continuous,  title={Continuous Performance Benchmarking Framework for ROOT},  author={Shadura, Oksana and Vassilev, Vassil and Bockelman, Brian Paul},  booktitle={EPJ Web of Conferences},  volume={214},  pages={05003},  year={2019},  organization={EDP Sciences}}

ROOTBench can be built standalone and as part of ROOT. If you want to enable ROOTBench for ROOT just add the-Drootbench=On option to your cmake configuration.

ROOTBench should be able to find ROOT at configuration time. Make sure you ransource $ROOTSYS/bin/thisroot.sh.

git clone https://github.com/root-project/rootbench.gitmkdir buildcd buildcmake ../rootbenchcmake --build. -- -j$(nproc)

also, you can use

cmake --build . -- -jN

where 'N' is the maximum number of processor cores you want to use.

ROOTBench relies onGoogle Benchmark. We recommend to read theavailable documentation and browse the existing exampleshere for more advanced usage.

This repository is being integrated in two steps:

• We run TravisCI on each pull request -- the public infrastructure is time limited and we use the latest ROOT nightly build available in CVMFS and EOS. This way we can integrate with public services such as Coveralls. Based on the TravisCI information we compute the benchmarking coverage of ROOTBench against ROOT. The idea is to make sure that we have well-distributed benchmarking coverage.
• We run on dedicated CERN OpenLab machines twice a day -- we build ROOT and ROOTBench from scratch and collect performance data. The data is uploaded to our Grafana service availablehere (requires CERN login).

The integration process depends on the overall benchmarking time. Contributors are encouraged to write well-focused microbenchmarks ensuring good benchmarking coverage. Non-overlapping microbenchmarks seem to be the only reasonable way to control the pressure on the infrastructure.

There are several practical conventions that we should follow:

• Coding conventions -- ROOTBench follows thecoding conventions of ROOT to a great extent.
• The routines used for benchmarking shall have the following namesBM_CLASSNAME_ROUTINE -- theBM prefix allows us (or tools) to easily identify which is the main benchmarking function.

Add file called CLASSNAMEBenchmarks.cxx where CLASSNAME is the name of the ROOT class we benchmark.

#include"ROOT_HEADER_TO_BENCHMARK.h"#include"benchmark/benchmark.h"// Replace the CLASSNAME and ROUTINE with the ROOT class and routine you are benchmarking respectively.staticvoidBM_CLASSNAME_ROUTINE(benchmark::State &state) {// Initialization section before actual benchmarking.for (auto _ : state) {// The benchmarking code goes here.  }// Teardown.}BENCHMARK(BM_CLASSNAME_ROUTINE);// In the end of the file we add our main().BENCHMARK_MAIN();

Register the benchmark in the system. Add an entry to theCMakeLists.txt next to the source code of the benchmark.

RB_ADD_GBENCHMARK(CLASSNAMEBenchmarks  CLASSNAMEBenchmarks.cxx  LABEL short  LIBRARIES LIST OF LIB DEPENDENCIES)

This is a very basic working example. If you need extra functionality please read theGoogle Benchmark Docs.