Roadmap

Last update: 14 March 2025

The ultimate goal of Adaptyst is addressing computational performance and procurement needs of software engineers, hardware designers, and administrators from high-energy physics and beyond. To achieve this aim, the project is being evolved towards a software-hardware co-design framework with the strong element of compilation along with interacting with existing tools.

This roadmap presents the details of the vision from two perspectives: technical and administrative. As mentioned on the homepage, news explaining the roadmap implementation progress is posted at least weekly and you’re welcome to follow it here. Please note that these plans are not permanently set in stone and can change during the development.

Technical#

The range of applications where computing is heavily used is wide, both at CERN and outside CERN:

• Embedded/Bare-metal/Edge computing: particle accelerator controls, trigger and data acquisition (DAQ) systems, industrial controls, radiation-hardened processors and controllers, Internet-of-Things, mobile data processing, …
• Standard computing: programs and games run on laptops and PCs/Macs, …
• Data centre / Grid / High-performance computing: various simulations and modelling, databases, particle track reconstruction, training machine learning models, HEP event generation, …

At the same time, the technological landscape is changing very rapidly, e.g. we are observing the slowdown of Moore’s law and Dennard scaling along with new hardware devices and software paradigms appearing. Furthermore, the need for high performance has not diminished and the importance of environmental sustainability is growing. It should also not be forgotten that non-compute parts of systems (such as memory, storage, networking, etc.) play a significant role in this context.

All of the above suggests the need for a comprehensive framework scaling across the entire computing spectrum, both workflow- and system-wise. For us, it is also important to ensure that users’ productivity is either maintained or boosted, especially in case of having to deal with large legacy codebases. Therefore, we want everybody to be able to adopt our framework with as few changes as possible to the way they write their code/workflows.

The present plan envisages a modular design of Adaptyst with its intermediate representation (IR) in the centre:

A workflow consisting of one or more user-configured workflow modules will be the starting point for every Adaptyst user. Every such module can be developed as an external plugin and will describe how a corresponding Adaptyst IR should be generated for a specific use case. Examples include running commands, processing a given code compilable to LLVM IR, etc. The resulting IR will have different parts assigned to a specific computer system entity and one or more modules within it (see below).

On the other side, Adaptyst will have access to a system prototype with a varying degree of flexibility and granularity. It will either be defined by a user, be detected automatically, or be a result of mixing both methods. The prototype will consist of one or more entities (imagine these as separate computers/servers) containing system component modules (imagine these as computer peripherals). Every such module can be also developed as an external plugin and will describe how a specific component should be modelled and profiled (if possible), how it can connect to other modules, and how a match between the component and the Adaptyst IR part should be calculated.

More specifically, a system component module will take an IR part and any assumptions (e.g. the average number of iterations of a given unbounded loop) as the input and return a mathematical function g along with information of interest for a user (e.g. profiling results). Afterwards, the match (a real number between 0 and 1 inclusive) will be calculated for various categories like throughput, energy efficiency, etc. as follows:

where h is a built-in Adaptyst function to be researched, X are optimisable software parameters, Y are optimisable hardware parameters, and beta are user constraints such as maximum power consumption.

When all necessary information is gathered, Adaptyst will find the best compute solution by optimising X and Y such that the matches of interest are maximised. This will ultimately include automatic system component matching and automatic IR part splitting, moving the burden of performance analysis to Adaptyst.

Compared to the existing work indicated in the Adaptyst introductory paper, Adaptyst will:

• expand easily to all workflow and system/hardware types now and in the future
• work with legacy codes and across programming languages with no explicit accelerated code separation required
• perform automated software-hardware co-design with the “big picture” view rather than just a merely “CPU vs GPU”-type one
• be always open-source

It should be noted that the envisaged design allows full flexibility with respect to the amount of software-hardware co-design: users will be able to choose how much software and how much hardware can be customised. Therefore, if desired, it will be possible to use Adaptyst as a typical software compiler/profiler or high-level synthesis tool.

The current version of Adaptyst is a code profiler utilising Linux “perf” with our own patches. This work fits very well into the planned design as shown in the diagram below. Moreover, the patched-“perf” arrangement will be replaced by an in-house equivalent not calling any “perf” APIs and not spawning any “perf” processes. While the research into this is still taking place, the replacement is likely to involve perf_event_open(2) system calls and eBPF in case of Linux.

Last but not least, there are various tasks which are more short-term in nature, such as addressing user feedback, fixing bugs, and improving Adaptyst in general. All of these along with roadmap-related technical activities can be found on GitHub (Adaptyst, Adaptyst Analyser) with the “roadmap” tag.

Administrative#

The Adaptyst development is a substantial task which would not be possible without funding and knowledge support.

Currently, i.e. until the end of December 2025, Adaptyst is supported by the SYCLOPS project funded by the European Union HE research and innovation programme (grant agreement No 101092877). Afterwards, given the heavy R&D presence in the roadmap, the development is planned to be carried out as part of PhD research in collaboration with CERN and a university research group in computer science/engineering for the next few years. The details are being discussed and will be shared as soon as they are confirmed.