MPDRoot is the software framework for simulation, reconstruction and physics analysis of the simulated and experimental data for MPD experiment at NICA. It is planned to obtain ~ 108 events of heavy ion collisions for physics analysis, hence it is crucial to have the effective and efficient methodology of the systematic performance improvement of MPDRoot's backend. In this work, we present the analysis of timing and instruction performance of MPDRoot's reconstruction by benchmarks and the Callgrind profiler. We evaluate the feasibility of speeding up reconstruction by the reduction of method-call overhead and the possible benefit of optimizing the math library. Based on the obtained results we draw conclusions about necessary steps to be taken in the near future of MPDRoot's development.
The architecture of MPDRoot is shown in Fig.1 and is composed of the three main parts [
Root – a set of building blocks and primitives written in C++ language, tailored for physics experiments FairRoot – simulation, reconstruction and analysis framework built on top of Root and the other set of packages encapsulated in FairSoft
MPDRoot – specific implementation for the MPD experiment at NICA
The process of optimization requires finding runtime bottlenecks, which is commonly
achieved by measuring performance of various software entities in units of time and instructions. For
this purpose, MPDRoot and FairSoft/FairRoot suite must be built with debug symbols. The
information about the instruction profile of various parts of the MPDRoot’s reconstruction is obtained
by running the Callgrind tool from the Valgrind suite [
However, from the practical point of view, it is the physical time the software spends in its given entity, which represents the true performance measure. The accurate measurement of such performance is somewhat problematic as it uses expensive system clock calls. If often used, these skew results and the direct timings of low-cost software entities are usually completely invalid. The pie chart in Fig. 2 shows the difference between the instruction profiler results and the true physical time for the various tasks of the MPDRoot’s reconstruction. This means, the instruction profile obtained from Callgrind is suitable for finding performance bottlenecks.
MPDRoot spends most of the time in digitizing (~45%) and clusterization (~48%) followed by the Kalman filter (~5%) and the Fair engine (less than 1%). Hence, it is logical to look into digitizer and clusterization algorithms for speedup optimization at the current stage of MPDRoot’s development.
It is possible to speedup the code by reducing the method-call overhead with the inline keyword (or the flatten attribute), however the result of code inlining is many times counterproductive [3]. In the most common case, the removal of the call stack results in a larger executable binary, which in turn slows down the execution time. The table in Fig.3 shows the effect of reducing the method -call overhead by inlining the most frequently called methods from Digitizer and ClusterFinder tasks. % instructions out of total instructions per call % of calls inlined CalcOrigin (Digitizer task) GetCij (ClusterFinder task) 4.8 12 18 380 100 90 task speedup 4.2% -1.2% total speedup 1.9% -6.3%
While inlining the cheap CalcOrigin method (18 instructions per call) results in an overall speedup by 1.9% of time, inlining the more expensive GetCij method (380 instructions per call) slows down the total runtime. Despite the obvious positive effect, inlining the CalcOrigin method at the current stage of development is not a good idea, as this method can be modified in the future.
Such a closed for modification, well tested software entity used in MPDRoot is the TMath library. The results of the benchmark of TMath methods running in MPDRoot are presented in the upper plot of Fig.4. The power, logarithm, and trigonometric are the most expensive methods.
If one is careful with cumulative errors, the quickest way to achieve speedup of math methods is to replace default double precision methods with their float precision analogues. Thus, one can get up to 45% speedup (bottom plot of Fig.4).
The plot in Fig.5 shows the instruction percentage of the five most present math methods in MPDRoot’s reconstruction. Overall, the whole TMath library takes less than 2.5% out of the total number of instructions, therefore any optimization of math library is currently not justifiable as it will not lead to any significant reconstruction speedup.
It is shown, that the effective methodology of MPDRoot’s optimization consists of firstly
isolating bottlenecks by timing benchmarks and instruction profiling. Out of those, the reasonable
candidates for optimization are entities already closed for modification in the MPDRoot’s
development lifecycle. Having such software entities in the MPDRoot’s codebase is necessary for
effective optimization. This means it is crucial to focus on improving the software quality, which will
in turn result in a well-tested modularized professional grade code [4], [5], [
We will implement the following changes to the MPDRoot’s software development process: 1. Implementation of the code ownership feature - essential for the code review process. 2. Implementation of the QA tests engine – to minimize risks associated with algorithm logic changes or extensions 3. Implementation of the unit test engine – to minimize risks associated with system changes or extensions
The work was supported by the RFBR grant (“Megascience – NICA”) No. 18-02-40102.