Performance interfaces are to performance what functional interfaces (documentation, header files, specifications, etc.) are to semantics: succinct descriptions of the performance one can expect when running that code. Unlike performance specifications and/or traditional performance models, performance interfaces are succinct and accessible to both average developers and tools.
Our research pursues three broad directions:
- Extracting performance interfaces from code or design docs, and using them to develop applications that meet their performance expectations
- Designing systems that exhibit predictable performance and are thus amenable to being described using a performance interface
- Verifying formally that systems code will indeed perform as advertised by its performance interface
Without functional interfaces, it would be inconceivable to build today’s systems. Performance interfaces are equally fundamental to tomorrow’s systems: while today one can still get by with profiling and trial-and-error, we do not believe that will last long.
We aim to improve upon decades’ worth of performance modeling in several ways:
- Previously proposed approaches tend to be specific to a particular context/setting. Instead, we propose an abstraction and representation for performance that can generalize across all types of systems.
- The audience of our work is programmers, and a performance interface is analogous to something they are deeply familiar with: functional interfaces. Having a similar abstraction for performance facilitates the assimilation of performance in programmers’ workflows as a first-class citizen.
- Modeling performance based on formal foundations enables us to precisely characterize the sources of approximation vis-à-vis implementations. The notion of resolution is an example of a formal mechanism for varying the level of abstraction in performance modeling that can be precisely controlled and understood.
Publications
- Performance Interfaces for Hardware Accelerators.
J. Ma, R. Iyer, S. Kashani, M. Emami, T. Bourgeat, G. Candea [ paper | code ] @OSDI ‘24 - Automatically Reasoning About How Systems Code Uses the CPU Cache.
R. Iyer, K. Argyraki, G. Candea [ paper ] @OSDI ‘24 - Achieving Microsecond-Scale Tail Latency Efficiently with Approximate Optimal Scheduling.
R. Iyer, M. Unal, M. Kogias, G. Candea [ paper | code ] @SOSP ‘23 - Latency Interfaces for Systems Code. R. Iyer [ PhD thesis ] EPFL 2023
- The Case for Performance Interfaces for Hardware Accelerators.
R. Iyer, J. Ma, K. Argyraki, G. Candea, S. Ratnasamy
[ paper ] @HotOS ‘23 - Performance Interfaces for Network Functions.
R. Iyer, K. Argyraki, G. Candea [ paper | code | talk video ] @NSDI ‘22 - Performance Contracts for Software Network Functions.
R. Iyer, L. Pedrosa, A. Zaostrovnykh, S. Pirelli, K. Argyraki, G. Candea [ paper | talk video ] @NSDI ‘19
Software
- LPN is a toolchain that let hardware developers to specify a performance-only model of their hardware accelerators with a representation called Latency Petri Net (LPN). The toolchain includes different tools that transform the LPN into different representations for different usages (performance interface, verification condition, fast simulator and formats for visualization).
- PIX is a toolchain that automatically extracts performance interfaces from software network function (NF) implementations. The resulting performance interfaces are accurate yet orders of magnitude simpler than the code itself, and they take mere minutes to extract
- Concord is a runtime that demonstrates how to achieve predictable, microsecond-scale control of execution time with low throughput overhead
- Bolt is a precursor to PIX, and it is used to automatically generate performance contracts for software network functions