rework intro for distributed simulations blog post

_posts/2024-09-04-distributed-simulations.md

@@ -9,33 +9,31 @@ permalink: /blog/distributed-simulations.html
 card_image: TODO
 ---
 
-SimBricks allows users to run full-system simulations by running multiple
-simulators as [separate loosely coupled processes](loosely-coupled-simulator-processes.html).
-Scaling up full-system simulations in SimBricks is usually as easy as adding
-more simulated components, where each new component is simulated by an
-additional simulator process. Additionally, SimBricks allows decomposition of
-some simulators into multiple instances running as different processes,
-preventing them from becoming a bottleneck while scaling up. We will further
-explore decomposition of simulators in a future blog post.
+SimBricks connects and runs multiple simulator components as
+[separate loosely coupled processes](loosely-coupled-simulator-processes.html),
+which all run in parallel. Scaling the system you want to simulate, i.e. adding
+more components therefore means running additional simulator processes. This
+approach naturally parallelizes the simulation and ensures that the simulation
+time stays low, but it also requires more resources, especially in form of
+physical CPU cores. In the following, we describe how SimBricks uses proxies
+leveraging network communication to distribute simulations across multiple
+machines.
 
-This approach naturally parallelizes the simulation and ensures that the
-simulation time stays low, but it also requires more resources, especially in
-form of physical CPU cores. Since SimBricks adapters are
-[polling shared memory queues](shm-message-passing.html), the simulator
-processes are always busy, which means that we should not oversubscribe the
-available CPU cores. Therefore, the size of a full-system simulation on one host
-is limited by its resources, requiring us to distribute the processes across
-multiple machines to scale the simulation beyond the limits of a single host. In
-the following we will cover how SimBricks uses proxies leveraging network
-communication to distribute simulations across multiple machines.
+# The Need For Scaling Beyond One Machine
+SimBricks uses
+[message passing over shared memory queues](shm-message-passing.html) for
+communication between the different simulator processes. For this the SimBricks
+adapters poll the shared memory queues, making the processes always appear busy,
+which means that we should not oversubscribe the available CPU cores. Therefore,
+the size of a full-system simulation on one host is limited by its resources,
+requiring us to distribute the processes across multiple machines to scale the
+simulation beyond the limits of a single host.
 
 # Scale Up By Using Separate Proxy Processes
-
-SimBricks uses message passing for communication between the different simulator
-processes. The communication between two simulator processes on the same host is
-implemented by shared memory queues. Scaling out simulations by partitioning
-components to multiple hosts can easily be accomplished by replacing the shared
-memory queues with network communication.
+While communication between two simulator processes on the same host is
+implemented by shared memory queues, scaling out simulations to multiple hosts
+can easily be accomplished by replacing the shared memory queues with network
+communication.
 
 However, directly implementing this in individual component simulators has two
 major drawbacks. First, it increases the complexity for
@@ -61,7 +59,7 @@ component simulators between two machines can be handled by the same pair of
 proxies. This reduces the number of proxies needed and therefore allows more CPU
 cores to be used for simulators.
 
-# Orchestrating Proxies
+# Orchestrating Distributed Simulations
 Simbricks' [orchestration framework](orchestration_framework.html) of course
 comes with support to use the proxies and distribute full-system simulations
 across multiple machines. The user can create a distributed experiment and add