ACALSim: Workload and Architectural Simulation

• ACALSim is a dual-use term describing two simulation frameworks in HPC: a Python-based workload-management simulator and a multi-threaded cycle-accurate architectural simulator.
• The early implementation, often called AccaSim, focuses on discrete-event scheduling to evaluate job dispatching and resource allocation in cluster environments.
• The later ACALSim offers a deterministic, parallel simulation framework for exploring design spaces in modern GPUs and AI accelerators with enhanced scalability.

Searching arXiv for the cited ACALSim/AccaSim papers and closely related simulation frameworks. arxiv_search query: (Galleguillos et al., 2018) AccaSim Customizable Workload Management Simulator Job Dispatching Research HPC Systems arxiv_search query: (Lin et al., 21 May 2026) ACALSim Scalable Parallel Simulation Framework High-Performance System Design Space Exploration arxiv_search query: SST simulator high performance computing simulation framework arXiv GPGPU-Sim Batsim Alea ACALSim designates two distinct simulation efforts in the HPC literature. In one usage, the name appears as an early-draft label for AccaSim, a Python discrete-event workload-management simulator for studying job dispatching in HPC systems (Galleguillos et al., 2018). In a later and separate usage, ACALSim denotes a multi-threaded simulation framework for cycle-accurate modeling and design-space exploration of tightly-coupled systems such as modern GPUs and AI accelerators (Lin et al., 21 May 2026). The shared label can therefore obscure a substantial shift in problem scope: the 2018 work centers on workload scheduling and resource allocation at the WMS level, whereas the 2026 framework targets architectural simulation infrastructure, deterministic parallel execution, and scalable single-node simulation.

1. Terminological scope and research context

The 2018 paper presents AccaSim, explicitly described as “a simulator for workload management in HPC systems,” with scalability to large workload datasets, support for easy customization, and automated tools for experimentation (Galleguillos et al., 2018). In the detailed description, AccaSim is also noted as being “sometimes referred to as ACALSim in early drafts.” This establishes that one occurrence of the term ACALSim is historical and aliases a workload-management simulator rather than a hardware simulator.

The 2026 paper introduces ACALSim as “a scalable parallel simulation framework” for high-performance system design-space exploration, with emphasis on modern GPUs and AI accelerators, intra-node scaling, and developer-controlled thread management (Lin et al., 21 May 2026). The paper states that timing-model accuracy remains the responsibility of simulator developers; the framework provides infrastructure and APIs rather than a universal timing model.

A common misconception is therefore to treat ACALSim as a single software lineage. The supplied literature instead documents two different artifacts with different implementation languages, abstraction levels, and evaluation targets. A plausible implication is that the acronym has become overloaded across adjacent HPC research areas: cluster workload management on one side, and cycle-accurate architectural simulation on the other.

2. AccaSim as a workload-management simulator

AccaSim is a discrete-event, workload-management simulator written in Python for rapid prototyping, customization, and evaluation of job dispatching algorithms in HPC systems (Galleguillos et al., 2018). Its architecture mimics a classical Workload Management System through five collaborating components: an optional Workload Generator, Job Submission, an Event Manager, a Dispatcher, and an optional Additional Data Interface. Output and tooling include a decision log, a resource-utilization/time-consumption log, a System Status CLI, a System Utilization GUI, a PlotFactory, and an experiment manager.

At the job level, the simulator represents a job through attributes including job ID, submission time $T_{sb}$, requested resources, and actual duration $p_j$, with optional duration estimation. The Event Manager maintains four job states—loaded, queued, running, and completed—and, at each simulated time $t$, performs a fixed sequence: loaded jobs with $T_{sb}=t$ are moved into the queue; the Dispatcher is invoked; jobs whose assigned start time equals $t$ become running and consume resources; and jobs whose completion time $T_c=T_{st}+p_j=t$ are marked completed and release resources.

The Dispatcher interacts with system state through two abstract hooks:

$t$1

This decomposition separates ordering decisions from placement decisions. The paper also states that the Dispatcher is unaware of true $p_j$ and may instead rely on a user-supplied estimate, which is a standard source of realism in scheduling studies because production WMSs rarely have oracle runtimes.

3. Input model, synthetic traces, and dispatching policies in AccaSim

AccaSim accepts workloads in SWF by default through DefaultReader, but the abstract Reader interface can be subclassed to ingest other file formats such as JSON and CSV, or direct streams such as databases and sockets (Galleguillos et al., 2018). After parsing, each job carries a Job ID, submission time $A_j=T_{sb}$, a requested resources vector $r_j$—for example cores, memory, and GPUs—and a duration $p_j$ from trace and/or an estimated duration.

Its synthetic trace generation pipeline is explicitly structured in three stages. Submission times use a modified Slot-Weight Method: the day is divided into 48 half-hour slots, each slot is weighted by its fraction of historical arrivals, an interarrival-day offset $p_j$0 is drawn up to the historic maximum, and the method walks the circular slot list while subtracting slot weights until the residual falls below the current slot weight. The maximum offset $p_j$1 is dynamically adjusted through a progress ratio $p_j$2 so that long-term hourly, daily, and monthly patterns match the original trace. Job type and size adapt Lublin–Feitelson’s algorithm to determine serial versus parallel behavior and number of nodes. Resource requests and duration are then derived by choosing resource quantities within user-supplied bounds, computing a random total FLOP requirement, and calculating duration from resource performance.

AccaSim exposes two abstract Python base classes for dispatching:

$t$2

The built-in schedulers are FIFO, SJF, LJF, and EBF (Easy Backfilling); the built-in allocators are First-Fit and Best-Fit. FIFO sorts by arrival time $p_j$3 ascending, SJF by estimated duration ascending, and LJF by estimated duration descending. EBF reserves space for the first job in queue, computes the head job’s earliest start time, and then dispatches later jobs in FIFO order if they fit into the holes before that head-job reservation. The allocator layer then maps jobs onto nodes or resource groups, with Best-Fit selecting the option with the least residual free capacity to reduce fragmentation.

AccaSim evaluates policy quality using standard scheduling metrics derived from the decision log, including average slowdown, makespan, throughput, and utilization (Galleguillos et al., 2018). The average slowdown is defined as

$p_j$4

and makespan as

$p_j$5

The simulator also tracks its own overhead through total CPU time, CPU time per dispatching decision, and memory footprint versus simulated job count.

4. ACALSim as a parallel framework for cycle-accurate architectural simulation

The 2026 ACALSim is a high-performance, multi-threaded simulation framework for cycle-accurate modeling and design-space exploration of tightly-coupled systems such as modern GPUs and AI accelerators (Lin et al., 21 May 2026). Its core features are listed as a deterministic two-phase parallel execution model, an event-driven engine with fast-forward optimization, a pluggable thread-management API, and a shared-memory data model supporting zero-copy communication.

The architecture is organized around SimTop, ThreadManager, a Worker Thread Pool, and a Shared Data Model. In Phase 1, worker threads execute each SimBase.step() in parallel, reading current state and writing into next-state buffers; only active components with pending events are scheduled. In Phase 2, the control thread waits at a barrier, flips ping/pong buffers for SimChannel, atomically commits next-state to current-state, advances globalClock to the next active cycle through fast-forward, and handles cross-component exchange and arbitration. The paper states that determinism is guaranteed because Phase 1 writes do not affect other components’ reads in the same cycle and all updates are committed simultaneously in Phase 2, independent of thread scheduling order.

The thread-management layer is explicitly extensible. ACALSim defines an abstract ThreadManager with initialize, scheduleTasks, synchronize, and shutdown, together with a TaskManager helper that provides default round-robin assignment. The detailed description names three example strategies: PriorityScheduler, which orders tasks by nextEventTime for sparse-activation workloads; WorkStealingScheduler, aimed at heavy, memory-intensive kernels; and LocalQueueScheduler, which uses thread-local task queues to eliminate global locks. The abstract interface is central to the paper’s claim that existing frameworks do not expose a mechanism for users to optimize threading for their specific workloads.

Communication and state sharing are mediated through three abstractions: SharedDataContainer<T>, SimChannel<T>, and SimPort (Lin et al., 21 May 2026). SharedDataContainer provides zero-copy access to shared structures such as workload DAGs and statistics; SimChannel is a directional, double-buffered queue with ping/pong semantics across the two phases; and SimPort models hardware-realistic ports with FIFO queues, round-robin arbitration, and backpressure callbacks. The memory layout is further optimized through a single POD SimPacket, a thread-local RecycleContainer object pool, and fixed-memory double buffering that removes per-cycle allocation.

5. Event-driven execution, APIs, and design-space exploration in ACALSim

The event engine is formulated around fast-forwarding to the next cycle with activity. The simulation loop computes

$p_j$6

advances the clock by the corresponding nonnegative increment, schedules active components, waits for synchronization, flips channel buffers, commits component state, and then advances to the next cycle if no fast-forward applies (Lin et al., 21 May 2026). The paper characterizes this as elimination of idle-cycle overhead.

The framework’s principal APIs are listed as SimTop, SimBase, SimPort<T>, SimChannel<T>, SharedDataContainer<T>, ThreadManager, and TaskManager. SimTop serves as the simulation entry point through methods such as setThreadManager(), loadConfig(), and run(). SimBase is the base class for hardware blocks via step() and commitState(). This API design indicates a separation between framework-level concurrency and model-specific timing semantics: developers compose simulators by building component graphs and supplying timing behavior inside SimBase.

Runtime configurability is JSON-based. The paper states that users can sweep the number of SMs—for example 64, 108, or 132—thread-block sizes per SM, L2 cache size and associativity, number of HBM channels, and NoC topology, including crossbar, mesh, and tree. It also provides an analytical performance sketch,

$p_j$7

where $p_j$8 is per-SM compute cost and $p_j$9 is Phase 2 overhead. The paper notes that users can fit this model to profiling data to predict simulation times for larger parameter sweeps.

A common misunderstanding would be to read ACALSim’s speedups as direct evidence of timing accuracy. The paper explicitly separates these concerns: ACALSim provides infrastructure and APIs for building high-performance simulators, while timing-model accuracy remains the responsibility of simulator developers (Lin et al., 21 May 2026).

6. Empirical results and comparative significance

The two systems are evaluated against different baselines because they address different research questions.

System	Evaluation focus	Representative reported results
AccaSim / early-draft ACALSim	WMS simulation for HPC job dispatching	On MetaCentrum, total simulation time 06:23 and memory footprint 19 / 19 MB; Batsim reports 29:29 and 12,647 / 15,431 MB; Alea reports 09:08 and 195 / 1,165 MB (Galleguillos et al., 2018)
ACALSim (2026)	Parallel architectural simulation infrastructure	Against an SST implementation with identical shared timing cores, over 14x speedup and 41% lower memory footprint; ACALSim reports 25.3 MB vs SST 43 MB (Lin et al., 21 May 2026)

For AccaSim, the authors compare against Batsim and Alea on three real traces: Seth with 202,871 jobs over 4 years on a 480-core system, RICC with 447,794 jobs over 5 months on an 8,192-core system, and MetaCentrum with 5,731,100 jobs over 2 years on an 8,412-core system (Galleguillos et al., 2018). Mean total simulation times over 10 runs are reported as 00:15, 00:27, and 06:23 for AccaSim on Seth, RICC, and MetaCentrum, respectively. The corresponding average/max memory footprints are 18/18 MB, 21/26 MB, and 19/19 MB. The paper attributes this near-constant memory behavior to incremental job loading and purging of completed jobs. In the Seth case study over the eight scheduler–allocator combinations $t$0, SJF and EBF are reported to yield the lowest median slowdowns, with EBF slightly better in mean slowdown. For overhead, the paper reports FIFO–FF at total simulation time 08:01, dispatch time 07:15, and average memory 76 MB, while EBF–FF reaches 22:24, 21:41, and 82 MB; dispatch time per decision grows almost linearly with queue size for EBF, whereas simple policies remain under 0.1 ms per invocation even with thousands of queued jobs.

For the 2026 ACALSim, the principal demonstration is HPCSim, a GPU simulator targeting A100-class architectures (Lin et al., 21 May 2026). HPCSim models 108 SMs, 32 L2 slices, a full-crossbar NoC, and 10 HBM2 controllers, with parameters configurable through JSON. On an Apple M2 Max using 8 worker threads, the wall-clock comparison against an SST-based implementation with identical shared timing cores reports GEMM 64³ at 0.64 s for ACALSim versus 0.11 s for SST, GEMM 256³ at 1.68 s versus 24 s, and GEMM 512³ at 9.03 s while SST times out beyond 102 minutes. The same table reports LLaMA-7B layer simulation in 17.7 minutes and LLaMA-13B layer simulation in 30.4 minutes, with SST not attempted for those workloads. The paper also reports hardware validation through cycle-count comparison against A100 measurements via Nsight Compute, with ratios ranging from 0.72× to 1.22× and a Pearson correlation coefficient of approximately 0.99. Its explanation for SST’s failure at 256 or more thread blocks is that SST ticks all components every cycle, lacks Phase 1 parallelism, incurs event serialization and serialize_order() overhead, uses credit-based flow control with additional bookkeeping, and suffers high context-switch or MPI overhead when scaled out.

Taken together, the two bodies of work show that the shared label ACALSim spans two different layers of HPC simulation methodology. The earlier usage, attached to AccaSim, addresses workload traces, dispatchers, allocators, and scheduler evaluation at the cluster-management layer. The later ACALSim addresses deterministic parallel execution, thread scheduling, shared-memory communication, and scalable simulator infrastructure at the architectural layer. This suggests that any technical discussion of “ACALSim” should first disambiguate which simulator is intended, because the associated abstractions, APIs, performance claims, and experimental baselines are not interchangeable.