Pith. sign in

REVIEW 4 major objections 5 minor 40 references

Towards Online Code Specialization of Systems

T0 review · 4 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read This paper argues that performance-critical systems code should be recompiled at runtime, with measured throughput instead of predictive cost models guiding the specialization choices.

desk verdict A well-motivated 'towards' paper with a real prototype and honest limitations; the unproven side-effect safety for irreversible I/O is the main reason it's not a full systems paper yet. read the letter →

arxiv 2501.11366 v1 pith:M5WT3S5Y submitted 2025-01-20 cs.SE cs.OS

Vaastav Anand , Deepak Garg , Antoine Kaufmann This is my paper · ORCID
classification cs.SEcs.OS
keywords onlinespecializationjust-in-timecompilationruntimecodepointsmeasurement-guidedexplorationnetworkstackscompile-timeconstantssystemperformance
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Manual specialization of low-level systems to hardware and workload is powerful but impractical: the optimal choices vary across machines and over time, and binding them at compile time is necessary for aggressive compiler optimizations. This paper proposes online specialization: a just-in-time (JIT) runtime that turns developer-designated variables into compile-time constants while the system runs, explores candidate values empirically, and switches when the workload changes. The point of the approach is to remove the human from the specialization loop and replace a-priori prediction with direct measurement of full-system performance. The paper's evidence comes from Iridescent, a prototype showing at least 50% cycle reductions on blocked matrix multiply, a 9% throughput gain on longest-prefix match, and automatic batch-size selection for a TCP acceleration stack.

What carries the argument

The load-bearing mechanism is the specialization point: a developer-annotated variable or parameter in the performance-critical handler that the runtime can fix to a value and feed to a JIT recompilation. Once fixed, the value is a compile-time constant, so ordinary passes such as constant propagation, dead-code elimination, loop unrolling, and vectorization apply to the whole function. Correctness is handled by a specialization check inserted at the function entry: if an incoming request's value does not match the specialized value, the runtime invokes a developer-registered cleanup function for side effects and transfers control to the generic version. An exploration engine collects the values seen, their frequencies, and check-failure counts, and uses these with the configured performance metric to decide which specialization to apply and when to switch. This combination—annotation, JIT, guard, and measurement-driven search—is what allows online specialization to replace static cost models.

What would settle it

Run Iridescent on a network function whose specialized code sends a packet to a neighbor before checking the specialization condition, then send an input that violates the condition; if the neighbor receives a second packet from the fallback path or the output is corrupted, the best-effort cleanup is insufficient for production use.

Watch

Extended reading notes

Core claim

The central claim is that specializing a variable to a constant at runtime is enough to let standard compiler optimizations cascade, and that doing so under measurement guidance is feasible for low-level systems code such as network stacks. The paper first shows, across five processor architectures and three matrix sizes, that the optimal tile size for blocked matrix multiply differs by machine and workload and that leaving it as a variable costs up to $6.5\times$ in performance. Iridescent then recompiles the handler with a candidate value fixed as a constant, inserts a guard that falls back to the generic version on mismatch, and explores the specialization space using measured cycles or throughput as the objective. The reported results are a 50% or greater reduction in cycles per execution when the block size becomes a constant, a 9% throughput increase for an incrementally specialized longest-prefix-match function, and automatic selection of three batch-size constants in a TCP acceleration stack.

Load-bearing premise

The scheme works only if every side effect performed before a specialization guard fails can be fully undone; the paper itself notes that not all side effects (such as sending a packet to a neighbor) are reversible, so its cleanup is best-effort.

Editorial extensions

If this is right

  • Systems can be deployed as a single generic build and specialize themselves to whatever hardware and workload they actually face.
  • Developers need only annotate specialization points and register cleanup functions; the runtime handles search and recompilation automatically.
  • Measurements of end-to-end latency or throughput can replace hand-built cost models for deciding between specialization choices.
  • The same online mechanism naturally handles workload changes: the runtime detects a throughput drop and restarts exploration.
  • Fixing one runtime variable to a constant can produce large gains (50% or more in the matrix-multiply case) because compiler passes cascade from that single change.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The side-effect guard problem is the main barrier to production adoption; placing specialization points only before irreversible operations, or making the cleanup transactional, would be a natural next step.
  • The measurement-guided search suggests a broader principle for compiler optimization: at deployment time, empirical search can outperform static cost models for many performance-sensitive code choices.
  • The technique should transfer to other low-level domains, such as storage stacks or kernel packet paths, whenever a handful of hot variables determine loop structure or memory access patterns.
  • One testable extension is to combine online specialization with profile-guided prefetching or domain-specific passes, since the paper's prototype only exploits constant-based optimizations so far.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes that performance-critical low-level systems be designed with and for online code specialization. It describes Iridescent, a JIT-based runtime that (i) takes developer-annotated specialization points (variables or parameters) in handler code, (ii) recompiles the handler with those points as compile-time constants, (iii) inserts guards that fall back to a generic version, and (iv) explores specializations using full-system performance measurements. The motivation is presented through blocked matrix multiplication, where the optimal block size depends on hardware and workload (Table 1). Three use cases are reported: turning the matrix-multiply block size into a constant (Table 3), partially specializing the LPM network function (9% throughput gain, Section 5.2), and exploring TAS batch-size configurations (Section 5.3). The paper claims feasibility, performance gains, and low developer effort for online specialization of low-level systems such as network stacks.

Significance. If the guard-fallback correctness issue is resolved, the proposal is significant because it offers a mechanism to obtain compile-time optimization benefits for deployed systems without manual recompilation and without relying on often-inaccurate cost models. The design is clearly presented, and the matrix-multiply results provide a concrete demonstration that converting a runtime variable into a constant enables cascading compiler optimizations. The authors also deserve credit for explicitly acknowledging the side-effect cleanup limitation in Section 4.2. However, the evidence is preliminary: there are no released artifacts, no error bars, no reproducible exploration policy, and the network-related results are either a single point (LPM) or lack a defined baseline (TAS). The central feasibility claim is therefore defensible but not yet fully supported.

major comments (4)
  1. [Section 4.2 and Section 3] The guard-fallback mechanism is the load-bearing correctness point, and the manuscript does not establish it. Section 3 says that when a guard triggers, 'we fall back to the original code version for this execution, incurring a performance penalty but no other problems,' but Section 4.2 says 'not all side-effects are reversible (e.g. sending a packet to a neighbor), so Iridescent performs a best-effort clean-up.' Best-effort cleanup is not a correctness guarantee: if the specialized handler performs an irreversible side effect before the check fails, the generic fallback cannot undo it, and externally visible outputs can be duplicated, dropped, or reordered. None of the three experiments in Section 5 exercises this case: MMulBlockBench is pure computation; the LPM specialization checks the hard-coded address at entry before routing; the TAS specialization is on internal batch-size constants and does not depend on per-request inputs, so guard failures never occur. Thus the evidence establishes at most that online specialization works when the developer can arrange for all irreversible side effects to happen after a successful check or when no check is needed, which is narrower than the abstract's claim of feasibility for 'network stacks.' The authors should either restrict the claim accordingly or demonstrate a mechanism (e.g., deferring or staging irreversible effects until after the guard succeeds) and evaluate a guard-failure case with a real side effect.
  2. [Table 3, Section 5.1] Table 3 contains internally inconsistent quantitative support for the headline speedup claim. For IvyBridge, the reported constant and variable cycle counts (250,434 and 661,295) give v/c = 2.64, i.e., 164% more cycles, not the reported 'Benefit' of 246%; the other rows show similarly irreproducible values (CoffeeLake gives v/c = 3.44, not 348%). The qualitative conclusion that the constant version is faster is plausible, but the exact magnitudes, including the claim of 'greater than 240% reduction' for four of five platforms, cannot be verified from the table as printed. The authors should correct the table or the surrounding text.
  3. [Section 5.2] The LPM result is reported as a single number: 'a 9% increase in the throughput.' No experiment detail is given: number of runs, variance or error bars, hardware, workload trace, rule-table size, monitoring-phase duration, or the exact baseline implementation. Since this is the only network-function throughput result, the paper should report a distribution over repeated runs and specify the experimental setup; otherwise the result is not distinguishable from measurement noise.
  4. [Section 5.3 and Figure 3] The TAS experiment does not define its baseline. The text says batch size is 'normally a fixed constant' but does not state what the default configuration is, what the unmodified TAS throughput is, how long exploration runs, or what the final selected configuration achieves relative to the baseline. Figure 3 shows the exploration trajectory with no confidence intervals and no baseline line; the 'Config Change' and 'Exploration' annotations are not explained in the caption. Moreover, Section 4.2 specifies the explorer engine only through the hooks and data collection; no concrete exploration policy is described, so the reader cannot assess whether the search would converge in general. Without this information, the claim that Iridescent 'can automatically select the best-configuration' is not verifiable.
minor comments (5)
  1. [Section 2, Section 5.2, Section 5.3] There are several typographical and grammatical errors, e.g., 'good peformance' in Section 2, 'Incremental computing and has been a mature idea' in Section 5.2, and 'non-baseline version' in Section 5.3. These should be cleaned up.
  2. [Section 4.3] No artifact or source-code availability statement is given for Iridescent; a repository or DOI would make the '3K lines of C++' prototype claim reproducible.
  3. [Table 1] Table 1 does not state how the 'optimal configurations' were determined; specifying the search method (single run, best-of-N, search over block sizes, etc.) would strengthen the motivating claim that the optimum is hard to predict a priori.
  4. [Figures 2 and 3] Figures 2 and 3 would benefit from error bars, run counts, and a clearer caption explaining the exploration phases and the baseline; Figure 2's y-axis is logarithmic, which should be stated in the caption.
  5. [Abstract and Section 4] The abstract claims 'low developer effort,' but no effort measurement is provided; at minimum, define what counts as developer effort (annotations, hooks, cleanup functions) and compare it to manual specialization effort.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: Iridescent's feasibility and performance claims rest on direct measurement, with acknowledged side-effect limitations that are not circular.

full rationale

The paper does not attempt a derivation; its central claim is that online specialization can improve performance and that an empirical search over measured end-to-end metrics can find good specializations. The MMulBlockBench, LPM/Vigor-Pix, and TAS results are demonstrations; the selected configurations are chosen by the same measured throughput/cycle objective used to report improvement, which is the intended methodology rather than a fit disguised as prediction. No fitted constant is reused as evidence: Table 1 and Table 3 establish by measurement that optimal block sizes differ across machines and workloads, and that compile-time constants outperform variables. Self-citations to Blueprint [3] and TAS [16] are incidental: Blueprint is named only for a future integration and TAS is an evaluation target, not a load-bearing premise; no uniqueness theorem or prior-work ansatz is invoked to force conclusions. The one genuinely load-bearing limitation is Section 4.2's admission that side-effect cleanup is best-effort and irreversible effects such as packet sends cannot be undone, which weakens the generality of the correctness/feasibility claim for network stacks; however, this is an explicit limitation, not a circular step. No equation or configuration is defined in terms of the result it is used to support.

Assumptions & free parameters 1 free parameters · 4 assumptions · 2 invented entities

The paper rests on four domain assumptions. The most fragile is the side-effect cleanup guarantee, which the paper itself acknowledges is only best-effort. The exploration search spaces are hand-picked but do not constitute fitted parameters in a derivation.

free parameters (1)
  • Exploration search spaces and durations
    The set of block sizes, batch sizes, and monitoring durations are hand-chosen by the authors; these choices affect the reported convergence and final performance in Figures 2 and 3.
assumptions (4)
  • domain assumption Turning a runtime variable into a compile-time constant triggers the expected cascading compiler optimizations and performance gains.
    Invoked in Section 3 as the key mechanism; supported empirically for the included workloads but not guaranteed for arbitrary code.
  • domain assumption Performance measured during the exploration window is stable and representative of steady-state behavior.
    The exploration engine in Section 4.2 selects configurations based on transient measurements; noisy neighbors or interference could make choices misleading.
  • ad hoc to paper Specialization checks and cleanup functions preserve correctness for all side effects.
    Section 4.2 admits irreversible side effects get only best-effort cleanup, so this axiom is not actually guaranteed; it is load-bearing for safe online specialization.
  • domain assumption Developer annotations correctly identify variables that are safe and valuable to specialize.
    The whole approach depends on developer intuition, stated in Section 3 as 'developers have excellent intuition'.
invented entities (2)
  • Iridescent specialization runtime
    purpose: A JIT-based runtime that recompiles handler code with specialized values and manages exploration.
    The central new component; no external validation or artifact released, only internal demonstrations.
  • Best-effort side-effect cleanup
    purpose: Roll back or contain side effects when a specialization guard fails.
    The paper states that not all side effects are reversible, so this entity cannot provide a correctness guarantee; its behavior for real network side effects is untested.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Towards Online Code Specialization of Systems." pith.science (2026). https://pith.science/paper/M5WT3S5Y

@misc{pith2026250111366,
  author       = {Pith},
  title        = {Pith review of: Towards Online Code Specialization of Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/M5WT3S5Y}},
  note         = {Machine review of arXiv:2501.11366}
}
read the original abstract

Specializing low-level systems to specifics of the workload they serve and platform they are running on often significantly improves performance. However, specializing systems is difficult because of three compounding challenges: i) specialization for optimal performance requires in-depth compile-time changes; ii) the right combination of specialization choices for optimal performance is hard to predict a priori; and iii) workloads and platform details often change online. In practice, benefits of specialization are thus not attainable for many low-level systems. To address this, we advocate for a radically different approach for performance-critical low-level systems: designing and implementing systems with and for runtime code specialization. We leverage just-in-time compilation to change systems code based on developer-specified specialization points as the system runs. The JIT runtime automatically tries out specialization choices and measures their impact on system performance, e.g. request latency or throughput, to guide the search. With Iridescent, our early prototype, we demonstrate that online specialization (i) is feasible even for low-level systems code, such as network stacks, (ii) improves system performance without the need for complex cost models, (iii) incurs low developer effort, especially compared to manual exploration. We conclude with future opportunities online system code specialization enables.

Figures

Figures reproduced from arXiv: 2501.11366 by the authors.

Figure 1
Figure 1. Iridescent design 4.1 System Modifications Source-Code Division. Developers divide the codebase into two parts: (i) the performance-critical handler code; (ii) the fixed code. The handler code is the set of functions and their dependencies in the codebase that the developer wishes to specialize. In contrast, the fixed code entails the general￾purpose part of the codebase that makes function calls into the handler co… view at source ↗
Figure 2
Figure 2. Automatic Exploration and Specialization of [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Automatic Exploration and Specialization of [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

40 extracted references · 39 canonical work pages

  1. [1]

    Improving storage systems using machine learning

    Ibrahim Umit Akgun, Ali Selman Aydin, Andrew Burford, Michael McNeill, Michael Arkhangelskiy, and Erez Zadok. Improving storage systems using machine learning. ACM Transactions on Storage, 19(1):1– 30, 2023

    work page 2023

  2. [2]

    In 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17), pages 469–482, 2017

    Omid Alipourfard, Hongqiang Harry Liu, Jianshu Chen, Shivaram Venkataraman, Minlan Yu, and Ming Zhang.{CherryPick}: Adaptively unearthing the best cloud configurations for big data analytics. In 14th USENIX Symposium on Networked Systems Design and Implementation (NSDI 17), pages 469–482, 2017

    work page 2017

  3. [3]

    Blueprint: A toolchain for highly-reconfigurable microservice appli- cations

    Vaastav Anand, Deepak Garg, Antoine Kaufmann, and Jonathan Mace. Blueprint: A toolchain for highly-reconfigurable microservice appli- cations. In Proceedings of the 29th Symposium on Operating Systems Principles, pages 482–497, 2023

    work page 2023

  4. [4]

    Automatic specialization of protocol stacks in operating system kernels

    Sapan Bhatia, Charles Consel, A-F Le Meur, and Calton Pu. Automatic specialization of protocol stacks in operating system kernels. In 29th Annual IEEE International Conference on Local Computer Networks , pages 152–159. IEEE, 2004

    work page 2004

  5. [5]

    Blocking linear algebra codes for memory hierarchies

    Steve Carr and Ken Kennedy. Blocking linear algebra codes for memory hierarchies. In PPSC, pages 400–405. Citeseer, 1989

    work page 1989

  6. [6]

    Cgptuner: a contextual gaussian process bandit approach for the automatic tuning of it configurations under varying workload conditions

    Stefano Cereda, Stefano Valladares, Paolo Cremonesi, and Stefano Doni. Cgptuner: a contextual gaussian process bandit approach for the automatic tuning of it configurations under varying workload conditions. Proceedings of the VLDB Endowment , 14(8):1401–1413, 2021

    work page 2021

  7. [7]

    Redundant logic elimi- nation in network functions

    Bangwen Deng, Wenfei Wu, and Linhai Song. Redundant logic elimi- nation in network functions. In Proceedings of the Symposium on SDN Research, pages 34–40, 2020

    work page 2020

  8. [8]

    Tuning database configuration parameters with ituned

    Songyun Duan, Vamsidhar Thummala, and Shivnath Babu. Tuning database configuration parameters with ituned. Proceedings of the VLDB Endowment, 2(1):1246–1257, 2009

    work page 2009

Show all 40 references
  1. [9]

    Packetmill: toward per-core 100-gbps networking

    Alireza Farshin, Tom Barbette, Amir Roozbeh, Gerald Q Maguire Jr, and Dejan Kostić. Packetmill: toward per-core 100-gbps networking. In Proceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems , pages 1–17, 2021

    2021

  2. [10]

    Packet order matters! improving appli- cation performance by deliberately delaying packets

    Hamid Ghasemirahni, Tom Barbette, Georgios P Katsikas, Alireza Farshin, Amir Roozbeh, Massimo Girondi, Marco Chiesa, Gerald Q Maguire Jr, and Dejan Kostić. Packet order matters! improving appli- cation performance by deliberately delaying packets. In 19th USENIX Symposium on N...

    2022

  3. [11]

    Just-in-time packet state prefetching

    Hamid Ghasemirahni, Alireza Farshin, Dejan Kostic, and Marco Chiesa. Just-in-time packet state prefetching. arXiv preprint arXiv:2407.04344, 2024

    2024 arXiv

  4. [12]

    Performance interfaces for network functions

    Rishabh Iyer, Katerina Argyraki, and George Candea. Performance interfaces for network functions. In 19th USENIX Symposium on Net- worked Systems Design and Implementation (NSDI 22) , pages 567–584, 2022

    2022

  5. [13]

    Apt-get: Profile-guided timely software prefetching

    Saba Jamilan, Tanvir Ahmed Khan, Grant Ayers, Baris Kasikci, and Heiner Litz. Apt-get: Profile-guided timely software prefetching. In Proceedings of the Seventeenth European Conference on Computer Sys- tems, pages 747–764, 2022

    2022

  6. [14]

    Datacenter RPCs can be general and fast

    Anuj Kalia, Michael Kaminsky, and David Andersen. Datacenter RPCs can be general and fast. In 16th USENIX Symposium on Networked Systems Design and Implementation , NSDI, 2019

    2019

  7. [15]

    In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), pages 1097–1114, 2023

    Ajaykrishna Karthikeyan, Nagarajan Natarajan, Gagan Somashekar, Lei Zhao, Ranjita Bhagwan, Rodrigo Fonseca, Tatiana Racheva, and Yogesh Bansal.{SelfTune}: Tuning cluster managers. In 20th USENIX Symposium on Networked Systems Design and Implementation (NSDI 23), pages 1097–1114, 2023

    2023

  8. [16]

    Sharma, Arvind Krishnamurthy, and Thomas Anderson

    Antoine Kaufmann, Tim Stamler, Simon Peter, Naveen Kr. Sharma, Arvind Krishnamurthy, and Thomas Anderson. TAS: TCP acceleration as an OS service. In 14th ACM European Conference on Computer Systems, EuroSys, 2019

    2019

  9. [17]

    LLVM: A compilation framework for lifelong program analysis & transformation

    Chris Lattner and Vikram Adve. LLVM: A compilation framework for lifelong program analysis & transformation. In 9th International Symposium on Code Generation and Optimization , CGO, 2004

    2004

  10. [18]

    Metis: Robustly tuning tail latencies of cloud systems

    Zhao Lucis Li, Chieh-Jan Mike Liang, Wenjia He, Lianjie Zhu, Wenjun Dai, Jin Jiang, and Guangzhong Sun. Metis: Robustly tuning tail latencies of cloud systems. In2018 USENIX Annual Technical Conference (USENIX ATC 18), pages 981–992, 2018

    2018

  11. [19]

    Adaptive code learning for spark configuration tuning

    Chen Lin, Junqing Zhuang, Jiadong Feng, Hui Li, Xuanhe Zhou, and Guoliang Li. Adaptive code learning for spark configuration tuning. In 2022 IEEE 38th International Conference on Data Engineering (ICDE) , pages 1995–2007. IEEE, 2022

    2022

  12. [20]

    {OPTIMUSCLOUD}: Heterogeneous configuration optimization for distributed databases in the cloud

    Ashraf Mahgoub, Alexander Michaelson Medoff, Rakesh Kumar, Sub- rata Mitra, Ana Klimovic, Somali Chaterji, and Saurabh Bagchi. {OPTIMUSCLOUD}: Heterogeneous configuration optimization for distributed databases in the cloud. In 2020 USENIX Annual Technical Conference (USENIX AT...

    2020

  13. [21]

    Domain specific run time optimization for software data planes

    Sebastiano Miano, Alireza Sanaee, Fulvio Risso, Gábor Rétvári, and Gianni Antichi. Domain specific run time optimization for software data planes. In Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems, ...

    2022

  14. [22]

    Emergent (mis) behavior vs

    Jeffrey C Mogul. Emergent (mis) behavior vs. complex software sys- tems. ACM SIGOPS Operating Systems Review , 40(4):293–304, 2006

    2006

  15. [23]

    Dataplane specialization for high-performance openflow software switching

    László Molnár, Gergely Pongrácz, Gábor Enyedi, Zoltán Lajos Kis, Lev- ente Csikor, Ferenc Juhász, Attila Kőrösi, and Gábor Rétvári. Dataplane specialization for high-performance openflow software switching. In Proceedings of the 2016 ACM SIGCOMM Conference , pages 539–552, 2016

    2016

  16. [24]

    Hoda: a high- performance open vswitch dataplane with multiple specialized data paths

    Heng Pan, Peng He, Zhenyu Li, Pan Zhang, Junjie Wan, Yuhao Zhou, XiongChun Duan, Yu Zhang, and Gaogang Xie. Hoda: a high- performance open vswitch dataplane with multiple specialized data paths. In Proceedings of the Nineteenth European Conference on Com- puter Systems, pages ...

    2024

  17. [25]

    Bolt: a practical binary optimizer for data centers and beyond

    Maksim Panchenko, Rafael Auler, Bill Nell, and Guilherme Ottoni. Bolt: a practical binary optimizer for data centers and beyond. In 2019 IEEE/ACM International Symposium on Code Generation and Optimiza- tion (CGO), pages 2–14. IEEE, 2019. Towards Online Code Specialization of ...

    2019

  18. [26]

    A categorized bibliography on incremental computation

    Ganesan Ramalingam and Thomas Reps. A categorized bibliography on incremental computation. In Proceedings of the 20th ACM SIGPLAN- SIGACT symposium on Principles of programming languages , pages 502–510, 1993

    1993

  19. [27]

    Incremental specialization of network programs

    Fabian Ruffy, Zhanghan Wang, Gianni Antichi, Aurojit Panda, and Anirudh Sivaraman. Incremental specialization of network programs. In Proceedings of the 23rd ACM Workshop on Hot Topics in Networks , pages 264–272, 2024

    2024

  20. [28]

    Autopilot: workload autoscaling at google

    Krzysztof Rzadca, Pawel Findeisen, Jacek Swiderski, Przemyslaw Zych, Przemyslaw Broniek, Jarek Kusmierek, Pawel Nowak, Beata Strack, Piotr Witusowski, Steven Hand, et al. Autopilot: workload autoscaling at google. In Proceedings of the Fifteenth European Conference on Computer...

    2020

  21. [29]

    Trimmer: application specialization for code debloating

    Hashim Sharif, Muhammad Abubakar, Ashish Gehani, and Fareed Zaffar. Trimmer: application specialization for code debloating. In Pro- ceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering, pages 329–339, 2018

    2018

  22. [30]

    Reducing the tail latency of microservices applications via optimal configuration tuning

    Gagan Somashekar, Amoghavarsha Suresh, Saurabh Tyagi, Vikas Dhyani, K Donkada, Anurag Pradhan, and Anshul Gandhi. Reducing the tail latency of microservices applications via optimal configuration tuning. In 2022 IEEE International Conference on Autonomic Computing and Self-Org...

    2022

  23. [31]

    In21st USENIX Symposium on Networked Systems Design and Implementation (NSDI 24) , pages 1101–1120, 2024

    Gagan Somashekar, Karan Tandon, Anush Kini, Chieh-Chun Chang, Petr Husak, Ranjita Bhagwan, Mayukh Das, Anshul Gandhi, and Na- garajan Natarajan.{OPPerTune}:{Post-Deployment} configuration tuning of services made easy. In21st USENIX Symposium on Networked Systems Design and Imp...

    2024

  24. [32]

    Soft- sku: Optimizing server architectures for microservice diversity@ scale

    Akshitha Sriraman, Abhishek Dhanotia, and Thomas F Wenisch. Soft- sku: Optimizing server architectures for microservice diversity@ scale. In Proceedings of the 46th International Symposium on Computer Archi- tecture, pages 513–526, 2019

    2019

  25. [33]

    In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), pages 177–194, 2018

    Akshitha Sriraman and Thomas F Wenisch.{𝜇Tune}:{Auto-Tuned} threading for{OLDI} microservices. In 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI 18), pages 177–194, 2018

    2018

  26. [34]

    Off-policy evaluation for slate recommendation

    Adith Swaminathan, Akshay Krishnamurthy, Alekh Agarwal, Miro Dudik, John Langford, Damien Jose, and Imed Zitouni. Off-policy evaluation for slate recommendation. Advances in Neural Information Processing Systems, 30, 2017

    2017

  27. [35]

    Automatic database management system tuning through large-scale machine learning

    Dana Van Aken, Andrew Pavlo, Geoffrey J Gordon, and Bohan Zhang. Automatic database management system tuning through large-scale machine learning. In Proceedings of the 2017 ACM international confer- ence on management of data , pages 1009–1024, 2017

    2017

  28. [36]

    P2go: P4 profile-guided optimizations

    Patrick Wintermeyer, Maria Apostolaki, Alexander Dietmüller, and Laurent Vanbever. P2go: P4 profile-guided optimizations. In Pro- ceedings of the 19th ACM Workshop on Hot Topics in Networks , pages 146–152, 2020

    2020

  29. [37]

    Iteration space tiling for memory hierarchies

    Michael Wolfe. Iteration space tiling for memory hierarchies. In Proceedings of the Third SIAM Conference on Parallel Processing for Scientific Computing, pages 357–361, 1987

    1987

  30. [38]

    More iteration space tiling

    Michael Wolfe. More iteration space tiling. In Proceedings of the 1989 ACM/IEEE conference on Supercomputing, pages 655–664, 1989

    1989

  31. [39]

    Tomur: Traffic- aware performance prediction of on-nic network functions with multi- resource contention

    Shaofeng Wu, Qiang Su, Zhixiong Niu, and Hong Xu. Tomur: Traffic- aware performance prediction of on-nic network functions with multi- resource contention. arXiv preprint arXiv:2405.05529, 2024

    2024 arXiv

  32. [40]

    Verifying software network functions with no verification expertise

    Arseniy Zaostrovnykh, Solal Pirelli, Rishabh Iyer, Matteo Rizzo, Luis Pedrosa, Katerina Argyraki, and George Candea. Verifying software network functions with no verification expertise. In Proceedings of the 27th ACM Symposium on Operating Systems Principles , pages 275–290, 2019

    2019

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.