Concurrency and Parallelism
Symaware is meant to run real time simulation connecting to all kinds of simulators, physics engines or even real robots.
As such, the simulation step, meaning the time it takes to run each component of the agent, as well as the environment, is a critical factor in the performance of the simulation.
Anything which is not in the order of milliseconds becomes noticeable and will affect the user experience.
There are cases when then computation load is too high and the threshold is not met.
Let’s investigate some of the possible workarounds based on the root cause of the problem.
Difference between Concurrency and Parallelism
First of all, it is important to understand the difference between concurrency and parallelism.
Concurrency is the ability of different parts or units of a program, algorithm, or problem to be executed out-of-order or in partial order, without affecting the final outcome. Concurrent tasks usually share the same memory (e.g. data structures, allocated storage), making communication easier. They may or may not run simultaneously, depending on the underlying architecture and the way the program is implemented.
Parallelism is the ability of a program to execute multiple parts or units simultaneously, each being run by a separate core or processor. Parallel tasks are independent for the most part, but can communicate and synchronize with each other if needed.
While they may seem similar and there is some overlap between the two, the results of employing one or the other can be drastically different.
Different kind of bottlenecks
Before diving into the solutions, it is also important to understand the different kinds of bottlenecks that can arise in a simulation (or any other kind of program, for that matter).
CPU-bound
A CPU-bound bottleneck occurs when the CPU is the limiting factor in the performance of the simulation.
This can happen when the simulation is computationally intensive, meaning that the CPU is constantly busy performing calculations and has little time to do anything else.
import time
# Running this function with a large value of n
# will require the cpu to perform a lot of operations,
# taking a long time to complete
def fibonacci(n: int) -> int:
if n <= 1:
return n
return fibonacci(n - 1) + fibonacci(n - 2)
I/O-bound
An I/O-bound bottleneck occurs when the input/output operations are the limiting factor in the performance of the simulation.
This can happen when the simulation requires a lot of data to be read from or written to disk, or when it needs to communicate with other systems over a network.
In this case, the CPU has to wait for the I/O operation to complete before it can continue with the next task.
import requests
# Running this function will require the program to wait
# for the response from the server, which can take a long time
# and is inherently orders of magnitude slower than a CPU cycle
def fetch_url(url: str) -> str:
response = requests.get(url)
return response.text
Concurrency and Parallelism in Python
When trying to achieve concurrency or parallelism in Python (CPython, to be precise), there is a notable obstacle one must overcome: the Global Interpreter Lock (GIL). The GIL is a mutex that protects access to Python objects, preventing multiple threads from executing Python bytecodes at once. In other words, no matter how many threads are spawned, only one of them can execute Python code at a time. As a consequence, it is not possible to achieve parallelism through threads.
This approach has its merits, as it makes managing race conditions and all sorts of complication arising from concurrent programming a non-issue. Threads can still be useful to handle blocking I/O operations, as for when the GIL is released, other threads can run, without having to busy-wait for the I/O operation to complete.
On the other hand, if the bottleneck is CPU-bound, the use of threads may even degrade the performance, as only one of them will run at any given time and the overhead of context switching between them will be added to the mix.
Multiprocessing
To achieve parallelism in Python, one must use the multiprocessing module, which allows the creation of separate sub-processes that can run in parallel.
Asyncio
There is a third way to achieve concurrency in Python, which is through the asyncio module.
This approach closely resembles the thread-based concurrency model, but with a few key differences.
Instead of using threads, asyncio uses coroutines, which are functions that can be paused and resumed at specific points.
This allows for a more fine-grained control over the execution of the program, as the programmer can explicitly define where the execution should yield control to another coroutine with the await keyword.
Moreover, the operating system is not involved in the context switch, making it more lightweight.
How to speed up slow simulations
Now that we have a better understanding of the different kinds of bottlenecks and the tools available to overcome them, let’s see how we can speed up slow simulations.
The first step is to identify the root cause of the problem.
Is the simulation CPU-bound or I/O-bound?
Then, it is important to determine whether the slowdown can be localized in a single component (or group of components).
If that’s the case, is strictly necessary to run it (or them) at the same frequency as the others?
Fast simulation
Assuming there is no bottleneck introduced by the framework’s components, the maximum pace of the simulation is determined by the simulator. The synchronous approach would be able to achieve the maximum performance with the minimum overhead.
class MyComponent(Component):
def _compute(self):
# Very fast computation
def main():
# ...
agent_coordinator = AgentCoordinator(...)
agent = Agent(AGENT_ID, AgentEntity(...))
agent.add_components(MyComponent(agent.id))
# ...
agent_coordinator.add_agents(agent)
agent_coordinator.run(TIME_INTERVAL) # This will run the simulation synchronously
which can be visualized as:
I/O-bound simulation
If the simulation is I/O-bound (e.g. it requires a lot of data to be read from disk or fetched from the network), the best approach is to use the asynchronous model. This way, all other components can run while the I/O operation is in progress, making the most of the available resources. Note that this means that the slow component will run less frequently than the others.
class MyComponent(Component):
async def _async_compute(self):
# I/O-bound computation
await # Some I/O operation
def main():
# ...
agent_coordinator = AgentCoordinator(...)
agent = Agent(AGENT_ID, AgentEntity(...))
agent.add_components(MyComponent(agent.id, TimeIntervalAsyncLoopLock(TIME_INTERVAL)))
# ...
agent_coordinator.add_agents(agent)
agent_coordinator.async_run() # This will run the simulation asynchronously
which can be visualized as:
CPU-bound simulation
If the simulation is CPU-bound (e.g. the operation is computationally expensive), the best approach is to use the multiprocessing model. Even if the computation itself is not parallelizable, running it in another process will avoid blocking the main one and allow other components to run in parallel. Combining this approach with the asynchronous model can yield even better results, as the slow component will wait for the parallel process to complete while the others can run uninterrupted. Note that this means that the slow component will run less frequently than the others.
def cpu_computation(i: int) -> int:
return i * i
class MyComponent(Component):
async def _async_compute(self) -> list[int]:
# Use multiprocessing to run the expensive computation in a parallel process
# In this case we are using a single process, but more can be added if needed
NUM_PROCESSES = 1
inputs = [i for i in range(NUM_PROCESSES)] # Example inputs
outputs = []
with ProcessPoolExecutor(max_workers=NUM_PROCESSES) as executor:
subtasks = [
asyncio.get_event_loop().run_in_executor(executor, cpu_computation, inputs[i])
for i in range(NUM_PROCESSES)
]
for task in asyncio.as_completed(subtasks):
outputs.append(await task)
return outputs
def main():
# ...
agent_coordinator = AgentCoordinator(...)
agent = Agent(AGENT_ID, AgentEntity(...))
agent.add_components(MyComponent(agent.id, TimeIntervalAsyncLoopLock(TIME_INTERVAL)))
# ...
agent_coordinator.add_agents(agent)
agent_coordinator.async_run() # This will run the simulation asynchronously
which can be visualized as:
Slow simulation at the same frequency
Unfortunately, there are cases when the slow component is necessary and must run at the same frequency as the others. The only option in this case is to either optimize the component computation in some way (e.g. using a more efficient algorithm or approximating the result) or slow down the simulation as a whole to accommodate the slow component. This is achieved automatically if the simulation is running in synchronous mode and the same will happen in asynchronous mode if the bottleneck is CPU-bound (see the asyncio section).
Some alternative approaches to side-step the problem outside the framework include running some precomputation before the simulation starts and caching the results of the slow component, or running the simulation on a more powerful machine.