Agent-Based Modeling (ABM) is a powerful technique for simulating complex systems through the interaction of individual agents, each following simple rules. However, the computational eficiency of ABM, especially in large-scale simulations, is often limited by the sequential nature of traditional methodologies. This paper presents an innovative approach to ABM using the Entity-Component-System (ECS) methodology, which adopts a data-oriented paradigm that prioritizes the model's logic over the complexity of the simulation. ECS, a software architecture commonly used in game development, decouples data (components) from behavior (systems), allowing for more granular control of each element. By applying ECS to ABM, the system's agents are treated as entities, with their characteristics stored as components and behaviors encapsulated in systems. This modular design enables the distribution of computational tasks across multiple processors or threads, enabling fine-grained parallelism and reducing bottlenecks commonly arising in traditional ABM frameworks. Our experiments on realworld use cases demonstrate that the ECS-based ABM ofers significantly higher parallel eficiency, particularly in scenarios with a large number of agents and complex interactions, while preserving ease of use and a reliable underlying structure.
Agent-based models (ABMs) have been proven efective in modeling real-world phenomena [
In this work, we present an experimentation of ECS (Entity-Component-System) within krABMaga [
In agent-based modeling, agents can be represented as entities, with attributes such as wealth or location defined as components. This analogy creates a natural link between ABM and the ECS model, merging the benefits of both worlds, such as performance and usability, without increasing complexity. Breaking down agents into individual components in ECS allows for better reusability and ifne-tuned control over each simulation aspect. Systems, such as a movement system, may update agent positions based on velocity components. ECS systems can also process entities in batches, enabling high-performance execution by applying the same operations to multiple entities within a system.
In ABM, large scale refers not only to simulations with many agents but also to the challenge of
managing the complexity of such simulations [
To the best of our knowledge, the ECS model has never been employed to implement an ABM engine. We have experimented with ECS to develop the visualization module, but it was not involved in the management of the entire simulation. For this reason, we aim to fill the gap in the literature investigating the feasibility of applying such a model in the context of ABM. Therefore, the research questions we aim to address in this paper are: • Is the ECS architecture feasible for use in agent-based modeling? Does it increase or decrease the dificulty of the development cycle? • Does the ECS architecture show an increase in performance? • How does the parallelized ECS model perform in agent-based simulations under high loads? Furthermore, we empirically evaluate the ECS model’s parallelization, examining its scalability and performance under high computational loads, testing the application on two well-known agent-based models.
ABM. Over the past decade, the research community has developed numerous software frameworks
and tools to support the creation of agent-based modeling simulations. These tools are often available as
software libraries for various programming languages and may be optimized for specific computational
platforms or tailored to particular application domains [
Parallel computation. One efective technique to boost computational performance is to redesign the
architecture or model to support parallel optimization. Parallel computation is a powerful method in
which multiple calculations or processes are executed simultaneously across multiple processing units,
enabling complex problems to be solved more quickly than would be feasible with a single processor [
In most agent-based modeling (ABM) toolkits, simulations usually follow a structured workflow divided into three phases: pre-step, step, and post-step. Each iteration corresponds to a discrete time step, with the step phase being essential and the others optional. The pre-step phase prepares the simulation by organizing agents, allocating resources, and scheduling entities. The step phase is the core of the simulation, executing the model’s main logic and handling agent behaviors and interactions. In the post-step phase, the toolkit finalizes tasks by updating shared data, releasing unused resources, and possibly performing data logging or analysis. This phased structure ensures eficient computation and supports scalability for complex models with many agents.
Specifically in krABMaga, the simulation progresses in steps using double bufering, meaning that agents scheduled at step cannot see any changes happening in the current step unless the modeler forces a read on the specific structure of the bufering. Instead, they only see the state of other agents, ifelds, and the simulation as they were at step − 1. This mechanism’s clear separation of read and write structures allows the engine to perform better on several tasks.
In sequential execution, as the paradigm suggests, each stage of the process must wait for the previous
one to complete, even when it is unnecessary. Moreover, the simulation’s logic, encapsulated in the step
phase, can be executed independently for each agent. This naturally leads to a scenario where parallel
execution is both possible and highly beneficial. However, the original architecture of krABMaga,
influenced by inherent features of the Rust programming language, limits the ease of writing parallel
code due to its strict concepts of ownership and borrowing [
By contrast, modeling an agent-based model using an ECS architecture ofers a more suitable approach. The main building blocks of an ECS are described as follows: • Entities: An entity is essentially a unique identifier that serves as a container for various components. Unlike objects in object-oriented programming, entities do not hold data or logic themselves; they are purely identifiers. This makes entities lightweight and flexible. 1https://unity.com/dots 2https://www.unrealengine.com/marketplace/en-US/product/apparatus 3https://github.com/skypjack/entt 4https://github.com/SanderMertens/flecs 5https://github.com/bevyengine 6https://github.com/amethyst/specs 7https://github.com/amethyst/legion 8https://github.com/Ralith/hecs 9https://github.com/leudz/shipyard • Components: Components are the pieces of data that define the characteristics or state of an entity.
Each component typically holds a single aspect of data, such as position, velocity, or health. • Systems: Systems contain the logic that operates on entities by modifying their components. They are responsible for processing data in a component-centric manner.
As mentioned earlier, ECS decouples data from behavior, facilitating the independent processing of agents and making the transition to parallel code much more straightforward. This decoupling enables better scalability and performance, particularly in large-scale simulations where parallel execution can significantly reduce computational time. The ECS design inherently aligns with parallelism by enabling simultaneous updates to entities without direct dependencies, making it an ideal solution for ABM simulations that require high performance.
The original version of KrABMaga leverages Bevy as its visualization module. Bevy is a straightforward, data-driven game engine that lets users take advantage of the ECS architecture within the Rust ecosystem. By default, Bevy supports highly parallel and cache-eficient programming. It ofers various features and libraries for making queries, managing global and local resources, and implementing a lock-free parallel scheduler.
To assess our framework, we adapted two widely used examples from the ABM field: the Boids
simulation [
First experiment. The initial implementation forcefully imposed parallelism on agent data structures using mutable queries for sheep and wolves. When a wolf detects and eats a sheep, it gains energy; the sheep must be removed, and the field updated to prevent other wolves from eating the same dead sheep. Parallel implementation proved challenging due to the overhead of mutually exclusive field updates.
This experiment showed that the focus should be on tracking sheep deaths and wolf energy gains per location. To overcome this, we implemented atomic counters tracking wolves per grid cell. The system processed sheep and grid in parallel, despawning appropriate sheep from each cell. Using wolf counts, sheep fields, and wolf locations, we calculated energy gains by computing the minimum between sheep and wolves per cell. This approach failed to improve performance because atomic operations introduced locks during execution, creating bottlenecks that did not resolve field update issues. Second experiment. The constraint that agents only interact within the same location was intended to isolate potential conflicts. Wolves kill sheep and gain energy in the same grid cell. The challenge was modifying wolves’ energy values during parallel execution, as Rust’s mutable objects cannot be shared across threads. To address this, we used locks, ensuring only one thread could access an agent’s data at a time. Instead of locking entire query objects, locks were applied directly to agents’ data, maintaining eficient parallel execution while satisfying Rust’s memory safety requirements.
Third experiment. The previous experiment did not fix the grid’s weak performance. Placing a lock on the entire grid would cause race conditions among agents. However, each agent only creates race conditions within its specific grid bag. Since we modify only the bag corresponding to the agent’s location rather than the entire grid, the solution is to place locks on individual bags. This allows locking only the required bag, reducing thread contention and improving parallel eficiency. Fourth experiment. Despite fixing some grid problems, agent management became a bottleneck. Spawning and despawning agents when they die or are born influenced engine performance. To optimize agent lifecycles, we replaced the spawning system with Bevy’s parallel system, which creates a bufer for the spawn_batch function. This allows instantiating all agents in a single call using an iterator containing initialization data, streamlining the process.
Current experiment. Previous attempts at the new implementation failed to improve performance across all critical sections of the architecture simultaneously. Each attempt addressed individual issues, but none provided a complete solution. The main bottlenecks were sequential field updates, agent spawning and despawning, and certain Bevy command executions. In the current implementation, which we refer to as the cemetery system, we aim to address all these issues concurrently, resulting in a more comprehensive and eficient approach. The cemetery system is a memory management technique designed to optimize memory reuse in simulations, especially when agents frequently die or need respawning. In traditional approaches, when an agent dies or is removed from the simulation, the associated memory is typically deallocated and must be reallocated later when a new agent spawns. Since this allocation-deallocation cycle repeats each iteration, it introduces performance overhead, especially in large-scale simulations where many agents are created and destroyed. In contrast, the cemetery system avoids this overhead by maintaining a pool of freed but unallocated memory locations when agents die. Instead of removing the memory entirely, the system places the memory of dead agents into a designated region called the cemetery. This region serves as a holding area, preserving space for future use. When new agents need to be created, the system reuses these empty cemetery spaces, assigning them to agents that require spawning. By reusing already-allocated memory, the cemetery system reduces frequent memory allocations, which are expensive in both time and system resources. The cemetery system operates within a single iteration window. Agent memory need not persist across the entire simulation, only during the current step. This approach enhances performance more granularly, avoiding overhead associated with Bevy’s internal functions, such as querying and reordering, which occur when managing entities.
To answer our research questions, we have tested Boids and WolfSheepGrass with the last architecture shown in the previous section (ECS with a cemetery system). The code for each attempt and benchmark is available as a GitHub repository 10. As a baseline, we measured the execution times of these models using the original sequential krABMaga implementation. Starting from 32000 agents, we have doubled this number to 2048000. The field size was selected to maintain an agent density of approximately 10%. Moreover, each configuration is tested on diferent numbers of threads, starting from 1 to 20, with an average elapsed time of 5 runs. The machine is configured as follows: • OS: Ubuntu 24.04.1 LTS x86_64 • CPU: Intel i9-14900KF @ 5.800GH (24 Cores, of which Performance-cores 8, Eficient-cores 16) • Memory: 64 GB 10https://github.com/Tonaion02/KrABMagaPersonalDev the table includes a "step" column, which highlights the performance improvements during the most computationally intensive tasks.
As discussed in the methodology section, the primary bottleneck in the simulation arises from updating the internal structure of the system. Up to 8 threads, there is a noticeable and consistent increase in speedup, reflecting eficient parallelization. However, beyond this point, the performance reaches a plateau. This plateau is due to the communication and synchronization overhead between threads, which becomes more pronounced as the number of threads increases. At this stage, the benefits of additional parallelism are ofset by the cost of managing inter-thread dependencies and coordination.
Figure 2a illustrates a snapshot of the initial implementation of the ECS methodology, as described in the previous section. The computation is divided into distinct phases, each occupying separate slots within a single iteration of the model’s execution. Notably, some of these phases overlap, meaning they must be executed sequentially, which extends the overall time required to complete each iteration. This segmentation reduces the potential for parallelism and introduces ineficiencies, as certain tasks must wait for the completion of others before proceeding.
Figure 2b shows the execution time of the WSG model in its final iteration, incorporating the cemetery system. In this implementation, entities are allocated at the start of the simulation. When an agent dies, instead of being deallocated, it leaves behind an empty space in the "cemetery," which can be reused for future agents in subsequent steps. This approach eliminates the overhead of dynamic memory deallocation and reallocation during runtime. As a result, the previously time-consuming 0,52 0,28 0,15 0,08 0,07 0,07 4,51 2,27 1,16 0,66 0,44 0,38
1 1,84 3,42 5,97 6,85 7,02
1 1,98 3,87 6,78 10,24 11,70
Step Count Wolves
Update Sheep Apply Commands
Grass Grow Update Fields
Step Cemetery System 0.8 (a) This snapshot captures a single iteration of the first (b) This snapshot shows a single iteration from the final implementation of ECS architecture. implementation of the ECS architecture. (a) Stacked values of the components in the last experi-(b) Total execution times of each simulation size varying ment. the number of threads. "apply commands" phase, which handled entity management, is now optimized and no longer consumes significant processing time. This improvement allows the system to more efectively parallelize operations, enabling simultaneous execution of diferent components of the simulation. The cemetery system thus contributes to a more eficient overall workflow, reducing bottlenecks and improving parallel performance.
Figure 3b shows the total execution time of the final implementation of the WSG model. The cemetery system is stable, reaching a constant value across diferent thread counts, showing that it no longer significantly influences the overall performance. The computation time for each step scales well with the increasing number of threads, although performance plateaus after reaching 8 threads. This suggests that the simulation benefits from parallelization up to a certain point, beyond which the overhead of synchronization and communication between threads becomes a bottleneck.
While the update fields still occupy a portion of the total execution time, the introduction of parallelism allows various field management tasks to be handled concurrently. As a result, the overall impact of the ifeld on the simulation’s total runtime is reduced.
Additionally, Figure 3b highlights the performance of the WSG model across various simulation sizes and thread counts. Notably, the performance plateau discussed earlier is not influenced by the size of the field or the number of agents. Instead, it is a direct consequence of the inherent limitations of the ECS architecture. This suggests that while the ECS framework provides certain advantages, its current implementation reaches a point where additional parallelism no longer yields significant performance improvements. Given this observation, future research should focus on exploring alternative methods for managing the diferent phases or structures of the simulation. By optimizing the organization and execution of the simulation’s various tasks, it may be possible to overcome the current performance bottleneck and achieve further gains in eficiency. 5.1. Limitations However, factors such as load balancing, synchronization costs, and the nature of agent interactions influence the level of parallel eficiency. In tightly coupled simulations, where agent interactions are frequent and complex, the overhead from synchronization ofsets the gains from parallelization. This is highlighted by the simulation’s plateau of performance, as shown in the previous chapter.
The framework was designed as a versatile tool to support a wide range of applications. However, this broad compatibility may result in certain components being less eficient due to the need for diverse use cases. To optimize performance and properly evaluate the benefits of this approach, additional workloads should be tested, and a code profiling should be conducted to fix issues such as caching or to evaluate the impact of tightly vs loosely coupled agents.
It is crucial to recognize that redesigning an engine for parallel architecture presents significant challenges, and the associated development costs must be carefully weighed when determining the feasibility of this solution.
This paper explored the parallel eficiency of an ABM engine built entirely on the ECS logic. The ECS architecture enables a clear separation of its elements by decoupling entities, components, and systems, thereby enhancing flexibility and modularity. Through parallelization, we aimed to improve the scalability and performance of ABM simulations, which are often computationally expensive due to the complex interactions between agents. Our results demonstrate that ECS provides a suitable framework for parallelizing ABM simulations, especially in scenarios with a large number of agents and interactions.
While this study has provided insights into the benefits and limitations of parallelization in ECS-based ABM engines, there are several areas for future exploration: • Investigating the use of heterogeneous computing resources, such as GPU and FPGA acceleration, in conjunction with ECS logic could ofer further performance gains. Understanding how to map ECS operations to these architectures will be a key challenge. • ECS architectures may incur overhead in memory usage due to the separation of components and systems. Future work could investigate memory optimization techniques to reduce the footprint of ECS-based ABM engines. • Expanding the benchmarking suite to include a wider variety of ABM scenarios, such as those with varying interaction complexity, agent heterogeneity, and environmental dynamics. • Exploring hybrid architectures that combine ECS with other modeling paradigms, such as standard discrete-event simulation, could lead to more eficient engines that leverage the strengths of each approach.
Future research can address these challenges to further optimize ECS-based ABM engines, enabling them to handle increasingly complex simulations while maximizing eficiency.
During the preparation of this work, the author(s) used Generative AI for grammar and spelling checks. After using these tool(s)/service(s), the author(s) reviewed and edited the content as needed and take(s) full responsibility for the publication’s content.