---
title: 'ACALSim: Workload and Architectural Simulation'
url: https://www.emergentmind.com/topics/acalsim
type: topic
---

# ACALSim: Workload and Architectural Simulation

Searching arXiv for the cited ACALSim/AccaSim papers and closely related simulation frameworks.
arxiv_search query: 1806.06728 AccaSim Customizable Workload Management Simulator Job Dispatching Research HPC Systems
arxiv_search query: 2605.22936 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 [1806.06728]. 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 [2605.22936]. 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 [1806.06728]. 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 [2605.22936]. 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 [1806.06728]. 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:

```python
schedule(queued_jobs, system_state) -> candidate_jobs
allocate(candidate_jobs, free_resources) -> (job→resource mapping)
```

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** [1806.06728]. 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 $v$ 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 $v_{max}$ is dynamically adjusted through a progress ratio $pr$ 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:

```python
class SchedulerBase:
    def schedule(self, queued_jobs, system_state) -> List[Job]

class AllocatorBase:
    def allocate(self, candidate_jobs, free_resources) -> Dict[Job,ResourceSet]
```

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 $A_j$ 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** [1806.06728]. The average slowdown is defined as
$$
\text{avg\_slowdown}=\frac{1}{N}\sum_{j=1}^{N}\frac{C_j-A_j}{p_j},
$$
and makespan as
$$
M=\max_j(C_j)-\min_j(A_j).
$$
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 [2605.22936]. 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** [2605.22936]. `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
$$
\delta = \min_i\{\text{eventQueue}_i.\text{nextTime}()\}-\text{globalClock},
$$
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 [2605.22936]. 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,
$$
T_{\text{sim}}(N_{SM}) \approx \alpha \cdot \lceil \text{work}/N_{SM}\rceil + \beta,
$$
where $\alpha$ is per-SM compute cost and $\beta$ 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 [2605.22936].

## 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 [1806.06728] |
| 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 [2605.22936] |

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 [1806.06728]. 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 $\{\text{FIFO},\text{SJF},\text{LJF},\text{EBF}\}\times\{\text{FF},\text{BF}\}$, **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** [2605.22936]. 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.

Source: https://www.emergentmind.com/topics/acalsim