SysPilot uses reusable library contracts to target software performance bottlenecks

Optimizing individual software libraries does not necessarily optimize an application built from them. A data loader, a numerical library and a machine-learning framework may each start their own workers, independently assuming that plenty of processing capacity is available. Together, they can create more runnable work than the hardware can efficiently support.

Yineng Yan, Haowei Chen and Christopher J. Rossbach propose addressing this problem with SysPilot, an autotuning prototype that combines reusable descriptions of library behavior with runtime measurements. Their paper, posted as an arXiv preprint on November 4, 2026, reports experiments across nine workflows. The supplied publication record does not establish peer-reviewed acceptance.

Describing what libraries need

SysPilot’s central idea is a Library Performance Contract: a machine-readable description of a library’s resource demands, operating assumptions, available configuration controls and useful monitoring signals. Here, “contract” means structured performance knowledge, not a guarantee of execution speed.

The authors introduce a specification language, LPCL, with a shared vocabulary for resources such as CPU capacity, GPU memory and storage bandwidth. That common vocabulary lets the system recognize that two otherwise different library components may compete for the same resource.

For example, an outer task scheduler can launch several jobs while a numerical library inside each job starts additional threads. Both layers consume CPU capacity. Increasing either layer’s parallelism may help in isolation but worsen contention when combined.

Contracts can be written by experts. SysPilot also includes a language-model-assisted pipeline that extracts evidence from documentation and code, then produces structured contracts. Evidence references support human auditing, while automated checks enforce the language’s structure. Those checks do not, by themselves, establish that every extracted claim is correct.

Suspicions must survive measurement

SysPilot compares contracts to generate hypotheses about resource conflicts. It then profiles the application, collecting signals such as runnable-thread counts, context-switch rates and memory use. Only hypotheses supported by the requested runtime evidence generate candidate configurations.

This distinction matters: two libraries mentioning the same resource is not proof that they cause a slowdown. Their work might occur at different times, or the hardware might have enough capacity for both. The contract analysis identifies possibilities; profiling tests their relevance to the current workload.

The tuner then evaluates configurations associated with supported hypotheses and accepts changes only when the chosen objective improves. Depending on the application, that objective can be elapsed time or throughput. SysPilot guides existing resource controls rather than replacing the mechanisms that enforce them.

What the experiments found

The researchers built LibContentionBench, comprising five synthetic-data workflows and four real-data applications. These cover interactions involving CPU workers, memory, storage access and GPU workloads. During tuning, input data and algorithmic settings remain fixed; exposed resource controls change.

Experiments ran on one dual-socket Intel server with 128 GB of memory and four NVIDIA Tesla P100 GPUs. The contract-generation evaluation used GPT-5.4. Comparisons included OpenTuner, SMAC3 and a SysPilot variant supplied with application-specific manuals instead of reusable contracts. All received the same legal tuning surface and objective.

After 30 candidate trials, contract-guided SysPilot achieved an average normalized score of 0.960, versus 0.935 for the manual-guided variant, 0.824 for SMAC3 and 0.729 for OpenTuner. The normalization measures progress from baseline performance toward an oracle reference; the figure caption describes that reference as the best observed across the four methods. It is not proof of a global optimum.

Contract-guided SysPilot reached an average normalized score of 0.8 in eight trials, compared with 24 for SMAC3. OpenTuner did not reach that threshold within 30 trials. The threefold reduction therefore concerns candidate executions at a specified quality target—not demonstrated threefold savings in total tuning time or cost.

One case study illustrates the mechanism: SysPilot identified thread controls that were inactive in the installed numerical-library build and removed them from consideration, focusing trials on settings that could affect execution.

Where the evidence stops

The authors acknowledge that incomplete documentation or language-model extraction errors can produce incomplete or inaccurate contracts. Profiling can reject suspected conflicts, but cannot reliably recover a conflict that the contracts and probes never identify.

Library versions, build options and backends also change behavior. The prototype lacks full version-aware compatibility checking and automatic contract aging. Its evaluation is limited to nine selected workflows on one machine, with distributed tuning left as future work.

The results support structured, reusable library knowledge as a promising way to focus configuration search. They do not establish universal speedups, guaranteed optimal settings or portability of the reported gains to other hardware and applications.