Demo Data from SIGIR 2026 / reviewers in the wild / expert
David Schall
dblp:321/3284
· DBLP profile ↗
6ranked-venue papers
4as first author
6since 2021 · last 2026
0000-0002-3587-3253ORCID · corroborated
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 6 · 4 first-author · 6 since 2021Software engineering, systems software and programming languages · 2 · 1 first-author · 2 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Computer architecture, parallel and distributed computing, and storage systems
6 papers |
Memory systems · 50% Processor architecture and microarchitecture · 22% Cloud and datacenter computing · 13% |
Topics — the 13 heaviest of 13, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Processor architecture and microarchitecture
branch prediction |
1.8 | 2 | 2026 | The Last-Level Branch Predictor Revisited · HPCA 2026 The Last-Level Branch Predictor · MICRO 2024 |
Memory systems
cache coherence |
1.3 | 2 | 2026 | C³: CXL Coherence Controllers for Heterogeneous Architectures · HPCA 2026 vCXLGen: Automated Synthesis and Verification of CXL Bridges for Heterogeneous Architectures · ASPLOS (2) 2026 |
Memory systems › memory consistency
memory consistency model |
1.3 | 2 | 2026 | C³: CXL Coherence Controllers for Heterogeneous Architectures · HPCA 2026 vCXLGen: Automated Synthesis and Verification of CXL Bridges for Heterogeneous Architectures · ASPLOS (2) 2026 |
Cloud and datacenter computing
serverless computing |
1.2 | 2 | 2023 | Warming Up a Cold Front-End with Ignite · MICRO 2023 Lukewarm serverless functions: characterization and optimization · ISCA 2022 |
Memory systems › cache coherence
cache-coherent interconnect |
1.0 | 1 | 2026 | vCXLGen: Automated Synthesis and Verification of CXL Bridges for Heterogeneous Architectures · ASPLOS (2) 2026 |
Memory systems › cache coherence
coherence controller |
1.0 | 1 | 2026 | C³: CXL Coherence Controllers for Heterogeneous Architectures · HPCA 2026 |
Electronic design automation › hardware verification and test
hardware verification |
1.0 | 1 | 2026 | vCXLGen: Automated Synthesis and Verification of CXL Bridges for Heterogeneous Architectures · ASPLOS (2) 2026 |
Memory systems › cache coherence › cache coherence protocol
heterogeneous coherence |
1.0 | 1 | 2026 | C³: CXL Coherence Controllers for Heterogeneous Architectures · HPCA 2026 |
Processor architecture and microarchitecture › branch prediction
TAGE predictor |
0.5 | 2 | 2026 | The Last-Level Branch Predictor Revisited · HPCA 2026 The Last-Level Branch Predictor · MICRO 2024 |
Interconnection networks and networks-on-chip › high-speed interconnect
CXL interconnect |
0.3 | 1 | 2026 | C³: CXL Coherence Controllers for Heterogeneous Architectures · HPCA 2026 |
GPUs and heterogeneous computing
heterogeneous architecture |
0.3 | 1 | 2026 | C³: CXL Coherence Controllers for Heterogeneous Architectures · HPCA 2026 |
Processor architecture and microarchitecture
microarchitectural state |
0.2 | 1 | 2023 | Warming Up a Cold Front-End with Ignite · MICRO 2023 |
Cloud and datacenter computing
cluster resource management and scheduling |
0.2 | 1 | 2022 | Lukewarm serverless functions: characterization and optimization · ISCA 2022 |
Methods — techniques the papers use, named apart from their topics
litmus testing · 1.0gem5 simulation · 1.0dynamic context depth adaptation · 1.0workload characterization · 0.6
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2026 | vCXLGen: Automated Synthesis and Verification of CXL Bridges for Heterogeneous ArchitecturesabstractCompute Express Link (CXL) offers byte-addressable, cache-coherent remote memory accesses across multiple hosts. Unfortunately, the CXL specification lacks mechanisms to ensure safe interoperability between heterogeneous host architectures with diverse cache coherence (CC) protocols and memory consistency models (MCMs). This semantic gap poses fundamental challenges and a significant barrier to adopting CXL in modern heterogeneous data centers. Anatole Lefort, Julian Pritzi, Nicolò Carpentieri, David Schall, Simon Dittrich, Soham Chakraborty 0001, Nicolai Oswald, Pramod Bhatotia |
ASPLOS (2) | 4 |
| 2026 | C³: CXL Coherence Controllers for Heterogeneous ArchitecturesabstractWe introduce$\mathbf{C}^{\mathbf{3}}$, a systematic methodology for designing Compute Express Link (CXL) coherence controllers, to overcome interoperability challenges that arise from the mismatch of coherence protocols and memory consistency models in heterogeneous CXL-connected systems. Crucially, CXL lacks a unified heterogeneous computing interface, which can lead to unpredictable and inconsistent behavior when multiple heterogeneous devices decide to share cache-coherent CXL memory. C$^{3}$acts as a pivotal interface between diverse heterogeneous compute units, bridging the semantic differences without necessitating disruptive changes to existing system architectures. Our approach hinges on two key principles: delegating memory operations across coherence domains and enforcing atomicity at domain boundaries, thereby preserving the native memory consistency model semantics of each unit. We implement$\mathbf{C}^{\mathbf{3}}$as a generic gem5 model and validate its correctness through exhaustive litmus testing. We also show that$\mathbf{C}^{\mathbf{3}}$incurs minimal performance overhead compared to unified native coherence protocols. Anatole Lefort, David Schall, Nicolò Carpentieri, Julian Pritzi, Soham Chakraborty 0001, Nicolai Oswald, Pramod Bhatotia |
HPCA | 2 |
| 2026 | The Last-Level Branch Predictor RevisitedabstractBranch prediction is critical for high-performance CPUs, with mispredictions causing significant execution inefficiencies. Modern server workloads exacerbate the challenge due to expanding instruction and branch working sets, while predictor capacities remain limited to avoid latency increases. A recently introduced hierarchical branch predictor design, LLBP, demonstrated a way to reduce misprediction rates by augmenting an unmodified TAGE-based predictor with a decoupled high-capacity metadata store. Despite using a large amount of storage, LLBP was shown to achieve only a fraction of the accuracy gain of an equal-sized (but impractical) TAGE-based predictor. This work provides a detailed analysis of LLBP, identifying sources of its accuracy loss. Chief among these are contention within certain sets of LLBP's high-capacity metadata store (namely those containing patterns for hard-to-predict branches), as well as duplication of patterns, which leads to prolonged training time. To address these issues, we propose dynamic context depth adaptation, an enhancement to the original LLBP design, which yields a significantly better distribution of patterns for hard-to-predict branches, thereby reducing both pattern set contention and pattern duplication. Our proposed design that realizes dynamic context depth adaptation requires only small modifications to the baseline LLBP while increasing its accuracy by 0.8-11.5 % (average 3.6 %). David Schall, Mária Duracková, Boris Grot |
HPCA | 1 |
| 2024 | The Last-Level Branch PredictorabstractBranch prediction is crucial for modern high-performance processors, ensuring efficient execution by anticipating branch outcomes. Despite decades of research, achieving high prediction accuracy remains challenging, particularly in server workloads, where large branch working sets and hard-to-predict branches are prevalent. State-of-the-art predictors, such as the 64KB TAGE-SC-L design, experience high misprediction rates on server workloads, with 3.6-20% (9.2% on average) of execution cycles wasted due to mispredictions on a modern server CPU. While more predictor capacity can reduce mispredictions by up to 36% in the limit (with infinite storage), realizing meaningful gains in practice requires hundreds of KBs of storage, which is infeasible for a latency- and area-sensitive in-core predictor. This work introduces the Last-Level Branch Predictor (LLBP), a microarchitectural approach that improves branch prediction accuracy through additional high-capacity storage backing the baseline TAGE predictor. LLBP leverages the insight that branches requiring longer histories tend to span multiple program contexts - notionally, function calls. A given program context, which can be thought of as a call chain, localizes the branch prediction state, affording a small number of patterns per context even for hard-to-predict branches. LLBP predicts upcoming contexts and prefetches the associated branch metadata into a small in-core buffer, which is accessed in parallel with the unmodified TAGE predictor. Our results show that a 512KB LLBP backing 64KB TAGE-SC-L reduces MPKI by 0.5-25.9% (avg. 8.9 %) over the baseline without LLBP. David Schall, Andreas Sandberg, Boris Grot |
MICRO | 1 |
| 2023 | Warming Up a Cold Front-End with IgniteabstractServerless computing is a popular software deployment model for the cloud, in which applications are designed as a collection of stateless tasks. Developers are charged for the CPU time and memory footprint during the execution of each serverless function, which incentivizes them to reduce both runtime and memory usage. As a result, functions tend to be short (often on the order of a few milliseconds) and compact (128–256 MB). Cloud providers can pack thousands of such functions on a server, resulting in frequent context switches and a tremendous degree of interleaving. As a result, when a given memory-resident function is re-invoked, it commonly finds its on-chip microarchitectural state completely cold due to thrashing by other functions — a phenomenon termed lukewarm invocation. David Schall, Andreas Sandberg, Boris Grot |
MICRO | 1 |
| 2022 | Lukewarm serverless functions: characterization and optimizationabstractServerless computing has emerged as a widely-used paradigm for running services in the cloud. In serverless, developers organize their applications as a set of functions, which are invoked on-demand in response to events, such as an HTTP request. To avoid long start-up delays of launching a new function instance, cloud providers tend to keep recently-triggered instances idle (or warm) for some time after the most recent invocation in anticipation of future invocations. Thus, at any given moment on a server, there may be thousands of warm instances of various functions whose executions are interleaved in time based on incoming invocations. David Schall, Artemiy Margaritov, Dmitrii Ustiugov, Andreas Sandberg, Boris Grot |
ISCA | 1 |