It is quite remarkable how Moore’s Law still prevails after more than half a century. Its consequences, however, have become very intricate. Rather than ever-increasing single-thread performance, today’s hardware provides performance improvements in the form of high degrees of parallelism, increasingly paired with growing heterogeneity. Beyond the need to express algorithms in a parallel and, ideally, re-targetable way, the hardware trends shift performance bottlenecks toward communication and synchronization across a pool of diverse resources. Hard- and software must tightly cooperate to achieve performance in this new world.
With MxKernel, we set out to re-think the interplay of hardware, system software, and applications in the light of the shifting hardware landscape and the tremendously growing demands on data processing capabilities. Classical system designs build on rigid interfaces that strictly separate concerns, e.g., between the “operating system”—in charge of managing resources—, the DBMS—responsible for managing data—, and applications, which are supposed to implement logic in a resource-oblivious way. Such a separation can hardly address the challenges that come with modern hardware. Applications have to jump through hoops to leverage modern hardware features. Classical system software stacks, on the other end, know very little about the actual characteristics and needs of individual applications. Under these premises, resource management essentially becomes a blind flight.
A key design goal of MxKernel, therefore, is to much better exchange such knowledge between the resource manager and the code running on top. We argue that threads are a poor basis to express the relevant knowledge. On commodity hardware, they are too course-grained; resource access patterns often change considerably over the lifetime of a thread. In a heterogeneous environment, featuring, e.g., FPGAs and/or GPUs, “threads” might not even have a sensible meaning in some of the hardware components. In MxKernel, the principal unit of reasoning are tasks—or MxTasks—instead. Tasks represent a unit of work to the system. Code-wise, they tend to be much smaller than classical threads; the equivalent of a single classical thread may fire a number of MxTasks in MxKernel. Since they relate to a very specific unit of work, tasks are a good abstraction for metadata that describes the characteristics of the unit.
The results of our research in the first funding period have been promising, but were obtained with small-scale benchmarks in a limited set of usage scenarios. Therefore, we plan to widen the set of supported application classes for a more systematic and comprehensive analysis. We also want to dig deeper into some of the findings and, hopefully, reap the fruits of our work in the first project phase. While we strive for finding an ideal system software architecture for future data processing needs, we also think about a migration path for existing system software. By learning on how to use contemporary computing hardware most efficiently, how to design system software interfaces that have the ability to gain knowledge on future application behavior, and the respective system software strategies, we can also improve the state-of-the-art incrementally.
