ArticlePDF Available

Extending ROOT through Modules

DOI:10.1051/epjconf/201921405011
Authors:
Oksana Shadura at University of Nebraska at Lincoln
Oksana Shadura
Brian Paul Bockelman
Brian Paul Bockelman
Brian Paul Bockelman
  • This person is not on ResearchGate, or hasn't claimed this research yet.
Vassil G Vassilev
Vassil G Vassilev
Download full-text PDF
Read full-text
Download citation

Abstract

The ROOT software framework is foundational for the HEP ecosystem, providing multiple capabilities such as I/O, a C++ interpreter, GUI, and math libraries. It uses object-oriented concepts and build-time components to layer between them. We believe that a new layering formalism will benefit the ROOT user community. We present the modularization strategy for ROOT which aims to build upon the existing source components, making available the dependencies and other metadata outside of the build system, and allow post-install additions on top of existing installation as well as in the ROOT runtime environment. Components can be grouped into packages and made available from repositories in order to provide a post-install step of missing packages. This feature implements a mechanism for the more comprehensive software ecosystem and makes it available even from a minimal ROOT installation. As part of this work, we have reduced inter-component dependencies in order to improve maintainability. The modularization effort draws inspiration from similar efforts in the Java, Python, and Swift ecosystems. Keeping aligned with modern C++, this strategy relies on forthcoming features such as C++ modules. We hope formalizing the component layer provides simpler ROOT installs, improves extensibility, and decreases the complexity of embedding ROOT in other ecosystems.
Available via license: CC BY
Content may be subject to copyright.
A preview of the PDF is not available
... Ideally, ROOT should allow building ROOT component or package on top of already pre-configured or pre-build ROOT. In order to make the ROOT packaging more flexible and less monolithic was introduced an idea of a ROOT-aware dependency manager [5], that could provide missing functionalities for ROOT. ...
... • ROOT-aware package manager prototype root-get: it can enable the ROOT-aware package management with the root-get prototype. [5] • OS package management (e.g. Fedora, Ubuntu and etc.): it will be easier to generate more granular ROOT packages. ...
Evolution of ROOT package management
Article
Full-text available
  • Apr 2020
ROOT is a large code base with a complex set of build-time dependencies; there is a significant difference in compilation time between the “core” of ROOT and the full-fledged deployment. We present results on a “delayed build” for internal ROOT packages and external packages. This gives the ability to offer a “lightweight” core of ROOT, later extended by building additional modules to extend the functionality of ROOT. As a part of this work, we have improved the separation of ROOT code into distinct modules and packages with minimal dependencies. This approach gives users better flexibility and the possibility to combine various build features without rebuilding from scratch. Dependency hell is a common problem found in software and particularly in HEP software ecosystem. We would like to discuss an improvement of artifact management (“lazy-install”) system as a solution to the “dependency hell” problem. HEP software stack usually consists of multiple sub-projects with dependencies. The development model is often distributed, independent and non-coherent among the sub-projects. We believe that software should be designed to take advantage of other software components that are already available, or have already been designed and implemented for use elsewhere rather than “reinventing the wheel”. The main idea is to build the ROOT project and all of its dependencies recursively and incrementally, making it fundamentally different than just adding one external project and rebuilding from scratch. In addition, this allows to keep a list of dependencies to be able to resolve possible incompatibility of transitive dependencies caused by the versions conict. In our contribution, we will present our approach to artifact management system of ROOT together with a set of examples and use cases.
View
... Ideally, ROOT should allow building ROOT component or package on top of already pre-configured or pre-build ROOT. In order to make the ROOT packaging more flexible and less monolithic and to develop a ROOT-aware dependency manager [5]. ...
Evolution of ROOT package management
Preprint
Full-text available
  • Jun 2019
ROOT is a large code base with a complex set of build-time dependencies; there is a significant difference in compilation time between the "core" of ROOT and the full-fledged deployment. We present results on a "delayed build" for internal ROOT packages and external packages. This gives the ability to offer a "lightweight" core of ROOT, later extended by building additional modules to extend the functionality of ROOT. As a part of this work, we have improved the separation of ROOT code into distinct modules and packages with minimal dependencies. This approach gives users better flexibility and the possibility to combine various build features without rebuilding from scratch. Dependency hell is a common problem found in software and particularly in HEP software ecosystem. We would like to discuss an improvement of artifact management ("lazy-install") system as a solution to the "dependency hell" problem. HEP software stack usually consists of multiple sub-projects with dependencies. The development model is often distributed, independent and non-coherent among the sub-projects. We believe that software should be designed to take advantage of other software components that are already available, or have already been designed and implemented for use elsewhere rather than "reinventing the wheel". In our contribution, we will present our approach to artifact management system of ROOT together with a set of examples and use cases.
View
Optimizing ROOT's Performance Using C++ Modules
Article
Full-text available
  • Oct 2016
ROOT comes with a C++ compliant interpreter cling. Cling needs to understand the content of the libraries in order to interact with them. Exposing the full shared library descriptors to the interpreter at runtime translates into increased memory footprint. ROOT's exploratory programming concepts allow implicit and explicit runtime shared library loading. It requires the interpreter to load the library descriptor. Re-parsing of descriptors' content has a noticeable effect on the runtime performance. Present state-of-art lazy parsing technique brings the runtime performance to reasonable levels but proves to be fragile and can introduce correctness issues. An elegant solution is to load information from the descriptor lazily and in a non-recursive way. The LLVM community advances its C++ Modules technology providing an io-efficient, on-disk representation capable to reduce build times and peak memory usage. The feature is standardized as a C++ technical specification. C++ Modules are a flexible concept, which can be employed to match CMS and other experiments' requirement for ROOT: to optimize both runtime memory usage and performance. Cling technically " inherits " the feature, however tweaking it to ROOT scale and beyond is a complex endeavor. The paper discusses the status of the C++ Modules in the context of ROOT, supported by few preliminary performance results. It shows a step-by-step migration plan and describes potential challenges which could appear.
View
ROOT — An object oriented data analysis framework
Article
The ROOT system in an Object Oriented framework for large scale data analysis. ROOT written in C++, contains, among others, an efficient hierarchical OO database, a C++ interpreter, advanced statistical analysis (multi-dimensional histogramming, fitting, minimization, cluster finding algorithms) and visualization tools. The user interacts with ROOT via a graphical user interface, the command line or batch scripts. The command and scripting language is C++ (using the interpreter) and large scripts can be compiled and dynamically linked in. The OO database design has been optimized for parallel access (reading as well as writing) by multiple processes.
View
YAML Ain’t Markup Language (YAML™) Version 1.2
  • Yaml
  • Org
Yaml.org. YAML Ain't Markup Language (YAML™) Version 1.2. [online] Available at: http://yaml.org/spec/1.2/spec.html [Accessed 6 Mar. 2019].
GitHub - apple/swift-package-manager: The Package Manager for the Swift Programming Language
  • Github
GitHub.GitHub -apple/swift-package-manager: The Package Manager for the Swift Programming Language. Available at: https://github.com/apple/swift-packagemanager. [Accessed 30 November 2018]. (2018)
GitHub -root-project/root: The official repository for ROOT: analyzing, storing and visualizing big data
  • Dec 2018
  • Github
GitHub.GitHub -root-project/root: The official repository for ROOT: analyzing, storing and visualizing big data, Available at: https://github.com/root-project/root. [Accessed 03 December 2018]. (2018)
GitHub - apple/swift: The Swift Programming Language
  • Github
GitHub. GitHub -apple/swift: The Swift Programming Language. Available at: https://github.com/apple/swift. [Accessed 30 November 2018]. (2018)
GitHub - root-project/root: The official repository for ROOT: analyzing, storing and visualizing big data Available at
  • Github