arXiv Science⌕ Search

arXiv · 2611.01904

Superscalar Loop Processors

Abstract

To sustain the computational demands of modern ML and HPC workloads, programmable accelerators integrate large arrays of processing elements (PEs), typically built around single-issue in-order cores to maximize integration density and energy efficiency. As a result, each PE's instruction throughput is upper-bounded at one instruction per cycle (IPC), often suffering from significant underutilization of its functional units (FUs). Conventional superscalar processors can improve FU utilization by increasing IPC, but they typically incur substantial area and energy overheads. This work proposes the Superscalar Loop Processor (SLP) architecture, a lightweight approach to superscalar execution that targets regular, compute-intensive loop kernels. We present the SLP execution model, which exploits the static structure of these workloads to enable efficient multiple-issue execution without the complexity of dynamic out-of-order scheduling. We demonstrate the SLP architecture through an open-source prototype implementation, Schnizo, developed as an enhancement of a tiny RV32I core with floating-point support. Across several ML and HPC microkernels, Schnizo achieves substantially higher IPC and FPU utilization than the scalar baseline while retaining the efficiency of lightweight in-order designs. These results demonstrate that SLPs can provide an efficient architectural solution for programmable accelerators targeting regular, compute-intensive workloads.

Explore related subjects

Keep this discovery

Explore connections, maps & timelines

BibTeXRIS

Luca Colagrande, Pascal Etterli, Luca Benini. 2026-11-01. Superscalar Loop Processors. https://arxiv.org/abs/2611.01904

Cite the original work for its findings. Save a collection to share your selection of sources.

KEEP EXPLORING

Related papers

Sustainable operation of research infrastructure for novel computing

Novel compute systems are an emerging research topic, aiming towards building next-generation compute platforms. For these systems to thrive, they need to be provided as research infrastructure to allow acceptance and usage by a large community. By the example of the neuromorphic BrainScaleS-2 system, we showcase the transformation from a laboratory setup to a publicly available research platform. It is embedded into a purpose-built institute, tightly coupling a conventional cluster with novel compute hardware. Our key contribution is the sustainable operation of such a research system: automation, integration, and resource separation enable maintainability, stable operation, and continuity in a fluctuating academic environment. We implement these concepts by adopting established best practices, such as network infrastructure with strong resource separation, 19-inch rack units, the integration of physical and simulated hardware into CI/CD processes, and system monitoring. We evaluate six years of platform operation comprising 3718 production deployments and an average of 198 hardware CI/CD runs per day, with the integration of simulated and physical hardware increasing the full-stack software line coverage from 57% to 79%. We conclude with an explicit collection of lessons learned during the transformation from single-user laboratory setups to a publicly accessible research platform that, since 2023, has served more than 520 individual researchers.

cs.AR↗

PIMCQG: Co-Designing Billion-Scale Graph-Based Approximate Nearest Neighbor Search for Processing-in-Memory

Graph-based Approximate Nearest Neighbor Search (ANNS) has emerged as the dominant approach for large-scale AI applications, offering superior accuracy-efficiency trade-offs over alternative methods. However, graph-based ANNS is inherently memory-bound due to frequent and irregular graph traversal. This constrains CPU throughput due to limited memory bandwidth, while GPUs lack sufficient HBM capacity for billion-scale indexes. Processing-in-Memory (PIM) offers massive internal bandwidth by co-locating computation with data, making it a natural fit for irregular, memory-bound workloads. However, directly mapping graph-based ANNS onto PIM exposes severe algorithm-architecture mismatches: restricted per-PU local memory, costly inter-PU communication, heavy coordination overhead, and weak compute capability, forcing existing PIM-based ANNS to rely on cluster-based algorithms that plateau at low recall. We propose PIMCQG, an algorithm-hardware co-design framework through three optimizations: (1) a compact index reducing PIM-resident footprint by 14.5x; (2) an asynchronous pipelined scheduler fully utilizing host-PIM bandwidth; and (3) a multiplication-free distance kernel with less than 0.08% recall loss. Evaluations on three billion-scale datasets show up to 20x/17.1x throughput over CPU/GPU baselines, 129x over prior PIM accelerators at high recall, and scale well across multi-node and emerging PIM architectures.

cs.AR↗

TEMPO: A Tag-Based Framework for Efficient Memory Ordering

Weak-memory processors rely on ordering instructions for correctness, yet conventional implementations often enforce them more conservatively than the memory model requires. This over-enforcement manifests as drain-induced retirement stalls at ordering instructions and conservative squash/replay of speculative loads, suppressing legal executions and reducing throughput. We present TEMPO, a tag-based framework for precise micro-architectural implementation of ordering instructions. TEMPO assigns lightweight ordering tags to instructions and decomposes enforcement across retirement-time predicates and completion-time store ordering, allowing the core to enforce required ordering without conservative retirement serialization. TEMPO eliminates unnecessary retirement serialization at ordering instructions and speculative-load squash/replay. In our evaluation, TEMPO reduces geometric-mean normalized execution cycles by 7.9% on native four-thread workloads and improves geometric-mean IPC by 15.9% on an instrumented SPEC2017 dynamic binary translation (DBT) proxy for cross- ISA execution (e.g., x86-on-Arm), while adding only 262 bytes per core.

cs.AR↗