We evaluate Elixir as a simulation runtime for opinion dynamics by implementing the same extended pairwise dialogue model in three engines with RNG parity: an Elixir actor engine, an Elixir task engine, and a Python multiprocessing baseline, ensuring identical outputs given the same seed. On a dense all-pairs stress test ( =300, =100, ∼ 4.5M dialogues), the actor engine was fastest; under a sparse random-matching topology (=8; 120k dialogues) the task engine outperformed actor by ≈ 18%. Both Elixir engines consistently exceeded Python. Ten repeated trials produced tight 95% confidence intervals, confirming stability and eficient multicore utilization on BEAM. We conclude that Elixir is a robust choice for high-concurrency agent-based simulations, with topology guiding engine selection (actor for dense, task for sparse). This runtime decision provides the methodological foundation for our subsequent modeling work.
Simulation of opinion dynamics in networked communities is a computationally demanding task.
Modern models, such as the extended pairwise dialogue framework [
Selecting an appropriate programming language and runtime environment is therefore critical. The requirements are precise: the simulation must support a large number of lightweight, independent computations, manage concurrency eficiently, and scale across modern multicore processors without significant programmer overhead. While Python is traditionally used in computational social science due to its extensive ecosystem of scientific libraries, its concurrency limitations pose non-trivial challenges for such workloads.
Other languages have also been employed for computational modeling. Julia [
In this paper, we argue that Elixir ofers unique advantages as the core simulation engine for opinion dynamics models. By evaluating the extended dialogue model in the challenging setting of = 300 agents under all pairs mode, we demonstrate that Elixir provides a scalable and robust foundation for simulation backends in computational social science. Importantly, this evaluation is not an end in itself but a methodological step: it was undertaken to identify the most suitable runtime for subsequent research on the dynamics of community opinions, where the extended dialogue model will be developed and applied at scale.
The study of opinion dynamics seeks to understand how individual preferences evolve through repeated
interactions within a community. In the extended dialogue model [
Unlike classical binary models, where agents either retain or adopt an interlocutor’s opinion, the extended framework introduces a third possibility: selecting an alternative state. As a result, each dialogue may lead to one of three outcomes:
2. An agent adopts the interlocutor’s opinion.
3. An agent rejects both options and transitions to a generalized alternative.
The likelihood of these outcomes is shaped by two independent attributes: resistance (the tendency to keep one’s own opinion) and persuasiveness (the ability to influence others). By decoupling these factors, the model captures more nuanced dynamics than deterministic consensus frameworks. For instance, when both agents exhibit high resistance and high persuasiveness, they may fail to persuade each other and instead converge on an alternative, reflecting real-world behaviors such as withdrawal from mainstream positions.
By explicitly modeling resistance and persuasiveness as independent attributes, the framework allows for richer dynamics than deterministic consensus models. For example, when both agents are highly resistant and highly persuasive, they may converge not on each other’s opinions but on an alternative, reflecting real-world behaviors such as rejection of mainstream narratives.
The dialogue process is formalized as a Markov chain. Each pair of interacting agents constitutes a state, defined by their current opinions. Transition probabilities between states are governed by the agents’ resistance ( ) and persuasiveness ( ) values. This leads to a stochastic transition matrix , where each row sums to one and encodes the likelihood of moving from one dialogue outcome to another.
The Markovian structure ensures that opinion evolution is both mathematically tractable and computationally eficient to implement, while still capturing non-trivial behaviors such as deadlocks, polarization, or convergence to alternatives.
Although conceptually simple, the extended dialogue model, where opinion updates occur through pairwise dialogues, becomes computationally demanding at scale. Suppose a network has agents and, in each iteration, every agent engages in dialogues with distinct peers (assuming dialogues are undirected): (, ) = 2
Over iterations, the total number of dialogue computations is · . Each dialogue triggers a probabilistic state update governed by the model’s transition rules, so runtime scales with both and , and .
To illustrate, consider a sizeable community with = 100,000 agents where each agent interacts with = 20 distinct peers per iteration (e.g., a dense social platform cohort or an enterprise communication snapshot). Then:
100,000 × 20 (100,000, 20) =
2 dialogues per iteration. Across = 1,000 iterations, that yields = 1,000,000 · = 1,000 × 1,000,000 = 10 9 dialogues — each an independent, lightweight computation whose outcomes must be aggregated into consistent agent states for the next iteration. This profile highlights three practical demands: • High volume of independent interactions (embarrassingly parallel within an iteration); • Natural concurrency (amenable to multi-core and distributed execution); • State management pressure (eficient aggregation and deterministic progression across iterations).
This workload profile requires a runtime capable of handling massive concurrency with minimal overhead while maintaining robustness over extended execution times.
Elixir, a functional programming language built on the Erlang virtual machine (BEAM) [
Elixir implements the actor model through lightweight processes that communicate via message passing. These processes are inexpensive to create and schedule, enabling thousands to run simultaneously on a single machine. In the context of opinion dynamics, this allows each agent or dialogue to be represented as an isolated process, mirroring the independence of interactions in the model. The result is a natural mapping between simulation logic and execution.
Long-running simulations can be disrupted by runtime errors, leading to incomplete or inconsistent results. Elixir addresses this with supervision trees, which monitor groups of processes and automatically restart them in case of failure. This design provides resilience without requiring explicit error-handling logic for every component, ensuring that simulations can run reliably over millions of dialogue steps.
The BEAM runtime also supports transparent distribution, allowing processes to span multiple CPU cores or even multiple machines with minimal configuration changes. Since dialogues are independent, distributing them across cores or nodes is straightforward, enabling simulations to scale horizontally as network size or iteration count increases.
Python remains the default language for computational modeling due to its extensive scientific libraries
and user-friendly syntax. However, its runtime is poorly suited for workloads dominated by massive
concurrency:
• The Global Interpreter Lock (GIL) prevents true parallel execution of threads on multiple cores. [
Dask [
Elixir integrates concurrency, fault tolerance, and distribution at both the language and runtime level. These properties make it particularly well-suited for large-scale opinion dynamics simulations, where each iteration involves thousands or even millions of independent dialogues across a network. By reducing implementation complexity and minimizing runtime overhead, Elixir ofers a compelling alternative to Python for executing the simulation core, particularly in scenarios that require sustained high concurrency and reliable long-running performance.
It is worth noting that recent developments in Python (PEP 703) [
Based on the requirements and architectural considerations outlined in the previous sections, we did an empirical comparison of Elixir and Python. The goal of these experiments was not to fine-tune implementations, but rather to observe how the two runtimes handle workloads characterized by large numbers of lightweight, independent interactions. Both languages were used to execute the same extended dialogue model under identical simulation parameters, enabling a direct assessment of concurrency handling, scalability, and robustness.
• Interaction pattern: all pairs — every agent interacts with every other agent in each iteration.
Although this pattern may not be realistic, it is employed as a worst-case stress test to maximize
computational load while keeping the model simple. By adopting the all-pairs setup, we avoid
additional complexity related to dynamically selecting subsets of peers and ensure that diferences
in runtime performance can be attributed directly to the eficiency of the execution environment.
• Total dialogues per iteration: ( ) = (︀ 2)︀ = (2−1) For = 300, this results in 44,850
dialogues per iteration.
• Iterations (T): 100.
• Attributes: Each agent is initialized with random values of resistance ( ∈ [
All experiments were conducted on a dedicated Amazon EC2 instance of type c8g.2xlarge [
The operating system was Ubuntu 24.04 LTS with kernel version 6.14.0-1011-aws. The software stack included: • Elixir 1.14.0 (compiled with Erlang/OTP 24), running on Erlang/OTP 25 [erts-13.2.2.5] with
JIT enabled. • Python 3.12.3, installed via the system package manager (apt).
• No external Python packages were required beyond the standard library.
Both implementations were installed from Ubuntu’s package repositories (apt) to ensure a consistent and reproducible setup.
The benchmarks were run on a dedicated instance without competing workloads.
To run the experiments, we developed three independent implementations of the extended dialogue model: two in Elixir and one in Python. Although they difer in architecture and concurrency approach, they all adhere to the same specification to guarantee deterministic parity of results. Shared design choices include: • All-pairs interaction at each iteration, with agent indices ordered ( < ) to enforce consistency in dialogue roles. • Random number generation (RNG) parity through a shared 64-bit Linear Congruential
Generator (LCG) [
• Rounding to three decimals at fixed stages, ensuring identical numeric results across languages.
It was explicitly validated that all three implementations return identical results given the same parameters and seed, confirming that observed diferences in performance are due solely to runtime characteristics rather than algorithmic divergence. Validation was performed by cross-checking outputs across engines, including per-agent preference vectors, average preferences, and vote distributions, ensuring complete agreement within rounding precision. 4.3.1. Elixir Task Engine Uses Task.async_stream to parallelize batches of pairwise dialogues. Each iteration generates all pairs, divides them into chunks, processes them concurrently, and then reduces the results to update agents’ states. 4.3.2. Elixir Actor Engine Implements an actor-based design, with one process per agent and a central Coordinator. Each iteration begins with a snapshot of agent states stored in ETS.Agent processes compute contributions against their peers and send results back to the Coordinator, which merges them and updates agent states. 4.3.3. Python Multiprocessing Engine Mirrors the Elixir Task Engine design, utilizing the multiprocessing module. Pairs are generated with < , partitioned into chunks, and distributed to worker processes. Results are collected, reduced per agent, and averaged.
To assess scalability, we measured execution time as the simulated community size increased, using the all pairs interaction pattern for 100 iterations.
We report results starting from = 100. Below this threshold, the number of dialogues per iteration is too small to produce meaningful performance comparisons, as runtimes are dominated by fixed overhead. At = 100, however, each iteration already requires 4,950 dialogues, yielding nearly half a million dialogues across the experiment, which is a substantial computational load.
Execution time grows in line with the quadratic complexity of the all-pairs configuration ( (︀ )︀ ), but 2 the rate and pattern of growth difer across implementations: • Elixir Actor Engine consistently delivers the best results across all tested community sizes.
Despite the coordination overhead of its GenServer design, it handles scaling more eficiently, leading to lower execution times throughout. • Elixir Task Engine performs well but is outpaced by the Actor engine even at small sizes, suggesting that its task scheduling overhead accumulates less favorably. • Python multiprocessing lags significantly behind both Elixir implementations. The gap widens with larger N, reflecting the steep cost of inter-process communication and serialization. 4.4.1. Throughput Analysis In addition to raw execution time, it is instructive to examine throughput, measured as the number of dialogues processed per second. Throughput was computed as:
Throughput =
Execution time (s) where the total dialogues equal the number of iterations (T = 100) multiplied by (︀ 2)︀ , and execution time was measured in milliseconds and converted to seconds.
Across all tested community sizes, Elixir Actor Engine consistently achieves the highest throughput, surpassing both Elixir Task Engine and Python. While Elixir Task Engine performs well, it is outpaced by the Actor engine, indicating that the GenServer-based design not only scales better but also processes Community size 250 300 dialogues faster in absolute terms. Python multiprocessing lags substantially behind, reflecting the cost of inter-process communication and serialization overhead.
It should be noted that these measurements are based on single runs per configuration. While absolute values may vary across repeated executions, the observed ordering of performance and relative scaling trends provide clear evidence of Elixir’s advantage as a simulation runtime.
Having established how execution time scales with community size, we next examine performance under fixed parameters by conducting repeated trials. This setting provides a complementary view, focusing on the stability and relative eficiency of the three implementations when the workload is held constant. 4.5.1. Benchmarking Methodology To ensure reliable and reproducible performance measurements, we developed a systematic benchmarking infrastructure. The methodology consists of three components:
Resource Monitoring. Each simulation run is monitored using the Python psutil library [
Metrics are sampled at 100ms intervals throughout execution. Memory is tracked per-process and summed across all descendants to capture the full resource footprint of concurrent implementations.
Statistical Analysis. Raw benchmark data from multiple trials are aggregated using a bootstrap
method [
This approach avoids distributional assumptions and provides reliable interval estimates even with small sample sizes (n=10 trials).
Execution Control. Benchmarks are orchestrated by shell scripts that execute each configuration multiple times with identical parameters (agents, iterations, seed, chunk size). Results are recorded in CSV format with one row per trial, enabling reproducibility and subsequent statistical analysis. All benchmarks were run on an isolated AWS EC2 instance (c8g.2xlarge, ARM64) without competing workloads to minimize measurement noise. 4.5.2. All-Pairs Topology Results
• Agents: 300 • Iterations: 100 • Interaction pattern: all pairs • Random seed: identical across engines and fixed across runs
The choice of 300 agents was deliberate. At this scale, each iteration requires (︀ 3020)︀ = 44,850 dialogues, and with 100 iterations, the run produces roughly 4.5 million dialogue computations. This ensures that runtimes are dominated by dialogue processing rather than initialization or warm-up overhead, which plays only a minor role at this load. At the same time, the workload remains tractable on the evaluation hardware (8 vCPUs, 16 GiB RAM) without exhausting memory, and lies within the range commonly used in opinion dynamics studies, where hundreds of agents are suficient to exhibit realistic aggregate behaviors without entering the territory of very large-scale distributed simulations.
Each implementation was executed ten times under these parameters. Table 1 reports the median runtime and 95% confidence intervals for each engine.
These results reinforce the conclusion that Elixir ofers clear performance advantages for highly concurrent workloads. Moreover, the stability across trials demonstrates that the observed diferences are not due to random noise but reflect genuine runtime characteristics. 4.5.3. Random Matching Topology To assess how interaction topology afects performance, we repeated the experiment using a random matching pattern instead of all-pairs. Under random matching, each agent is paired with = 8 randomly selected distinct peers per iteration, reducing the number of dialogues from (︀ )︀ to 2· . 2
With 300 agents, = 8 peers, and 100 iterations, random matching produces 120,000 total dialogues — a 97.3% reduction compared to the 4.5 million dialogues in the all-pairs configuration. This sparser interaction pattern more closely resembles realistic social network dynamics where agents engage in limited interactions per time step.
All other experimental parameters remained identical: • Agents: 300 • Iterations: 100 • Random seed: identical across engines and fixed across runs • Trials: 10 repeated runs per engine
These findings highlight that topology matters for runtime selection. While the Actor engine excels at dense all-pairs interactions where massive concurrency is available, the Task engine becomes more eficient for sparse topologies where coordination overhead dominates. Python remains consistently slower regardless of topology, though the performance gap narrows as computational intensity decreases.
This work examined the suitability of Elixir as a runtime environment for large-scale simulations of opinion dynamics. Using the extended dialogue model under two distinct interaction topologies — dense all-pairs and sparse random matching — we compared three implementations: an actor-based Elixir engine, a task-based Elixir engine, and a Python multiprocessing baseline. The purpose of this evaluation was not to establish a general benchmarking framework, but to support the authors’ ongoing research on community opinion dynamics by identifying a runtime environment that balances correctness, reproducibility, and performance.
The experiments demonstrated that Elixir provides clear advantages for highly concurrent workloads, though the optimal implementation varies with topology. For dense all-pairs interactions (4.5 million dialogues), the Actor engine excelled with superior parallelization and throughput. For sparse random matching (120,000 dialogues with = 8 peers per agent), the Task engine proved more eficient, as coordination overhead became proportionally more significant than raw dialogue processing. Python multiprocessing consistently lagged behind both Elixir implementations regardless of topology, showing 56–200% longer runtimes and varying CPU utilization patterns (593% for all-pairs, 660% for random matching vs. 629–732% for Elixir). The results confirm that the concurrency-first design of the BEAM runtime ofers tangible benefits for agent-based simulations that require millions of independent, lightweight interactions to be executed and aggregated deterministically.
At the same time, several limitations must be acknowledged. 1. The current implementations were evaluated on a single 8-core instance, and while they scaled well up to a few thousand agents, attempts to simulate 10,000 agents failed due to memory limitations. This highlights the need for further optimization and, potentially, distributed execution to extend the approach to larger communities. 2. While we evaluated two topologies (all-pairs and random matching with = 8), exploring additional realistic network structures such as scale-free networks, small-world topologies, or dynamic community detection remains an important direction for future work. 3. Emerging Python runtimes with no-GIL support (PEP 703) may alter the performance landscape.
A systematic evaluation of these builds is left for future work, as they are not yet mainstream and their ecosystem support remains limited.
Having established Elixir as a suitable choice, the next steps of the work will focus not on further runtime benchmarking, but on advancing the modeling itself: exploring richer agent attributes, network topologies, and empirical calibration. The following directions, therefore, outline the substantive research agenda beyond the technical runtime decision.
• Overcoming the 10k-agent barrier: optimize memory usage and explore distributed execution strategies across multiple nodes. • Alternative interaction topologies: extend experiments to include scale-free networks, smallworld structures, and community-based topologies with varying density patterns. • Distributed scalability: test Elixir’s native distribution capabilities in larger clusters to evaluate horizontal scaling. • Dynamic agent attributes: allow resistance and persuasiveness to evolve with interaction history, making simulations more realistic. • Empirical calibration: integrate data from surveys or social media to validate and tune model parameters. • Hybrid workflow: employ Elixir for running large-scale simulations while using Python’s mature ecosystem for post-simulation data analysis and visualization.
During the preparation of this work, the authors used ChatGPT and Grammarly to: Grammar and spelling check, Paraphrase and reword. After using this tool/service, the authors reviewed and edited the content as needed and take full responsibility for the publication’s content.