4 Any SimGrid simulation comes down to a set of **actors** using some
5 **resources** through **activities**. SimGrid provides several kinds of
6 resources (link, CPU, disk, and synchronization objects such as mutex
7 or semaphores) along with the corresponding activity kinds
8 (communication, execution, I/O, lock). SimGrid users provide a
9 platform instantiation (list of interconnected resources) and an
10 application (the code executed by actors) along with the actors'
11 placement on the platform.
13 The actors (ie, the user code) can only interact with the platform
14 through activities, that are somewhat similar to synchronizations.
15 Some are very natural (locking a mutex is a synchronization with the
16 other actors using the same mutex) while others activities constitute
17 more original synchronization: execution, communication, and I/O have a
18 quantitative component that depends on the resources. But still,
19 writing some data to disk is seen as a synchronization with the other
20 actors using the same disk. When you lock a mutex, you can proceed
21 only when that mutex gets unlocked by someone else. Similarly, when you
22 do an I/O, you can proceed once the disk delivered enough performance
23 to fulfill your demand (along with the concurrent demands of the other
24 actors occurring at the same time). Communication activities have both a
25 qualitative component (the actual communication starts only when both
26 the sender and receiver are ready to proceed) and a quantitative
27 component (consuming the communication power of the link resources).
29 The design of SimGrid is shaped by several design goals:
31 - **reproducibility**: re-executing the same simulation must lead to
32 the exact same outcome, even if it runs on another computer or
33 operating system. When possible, this should also be true when you
34 use another version of SimGrid.
35 - **sweet spot between accuracy and simulation speed**: running a given simulation should be as fast as possible but predict
36 correct performance trends (or even provide accurate predictions when correctly calibrated).
37 - **versatility**: ability to simulate many kinds of distributed systems
38 and resource models. But the simulation should be parsimonious too,
39 to not hinder the tool's usability. SimGrid tries to provide sane
40 default settings along with the possibility to augment and modify
41 the provided models and their default settings.
42 - **scalability**: ability to deal with very large simulations. In the
43 number of actors, in the size of the platform, in the number of
44 events, or all together.
49 The first crux of the SimGrid design lays in the interaction between
50 each actor and the activities. For the sake of reproducibility, the
51 actors cannot interact directly with their environment: every
52 modification request is serialized through a central component that
53 processes them in a reproducible order. For the sake of speed, SimGrid
54 is designed as an operating system: the actors issue **simcalls** to a
55 simulation kernel that is called **maestro** (because it decides which
56 actors can proceed and which ones must wait).
58 In practice, a SimGrid simulation is a suite of so-called **scheduling
59 rounds**, during which all actors that are not currently blocked on a
60 simcall get executed. For that, maestro passes the control flow to the
61 code of each actor, that are written in either C++, C, Fortran or Python.
62 The control flow then returns to the maestro when the actor
63 blocks on its next blocking simcall. Note that the time it takes to
64 execute the actor code has to be reported to the simulator using
65 execution activities. SMPI programs are automatically benchmarked
66 while these executions must be manually reported in S4U. The simulated
67 time is discrete in SimGrid and only progresses between scheduling
68 rounds, so all events occurring during a given scheduling round occur
69 at the exact same simulated timestamp, even if the actors are usually
70 executed sequentially on the real platform.
72 .. image:: img/design-scheduling-simulatedtime.svg
76 To modify their environment, the actors issue either **immediate
77 simcalls** that take no time in the simulation (e.g.: spawning another
78 actor), or **blocking simcalls** that must wait for future events (e.g.:
79 mutex locks require the mutex to be unlocked by its owner;
80 communications wait for the network to provide enough communication
81 performance to fulfill the demand). A given scheduling round is
82 usually composed of several sub-scheduling rounds during which
83 immediate simcalls are resolved. This ends when all actors are either
84 terminated or within a blocking simcall. The simulation models are
85 then used to compute the time at which the first next simcall
86 terminates. The time is advanced to that point, and a new scheduling
87 round begins with all actors that got unblocked at that timestamp.
89 Context switching between the actors and maestro is highly optimized
90 for the sake of simulation performance. SimGrid provides several
91 implementations of this mechanism, called **context factories**. These
92 implementations fall into two categories: Preemptive contexts are
93 based on standard system threads from the libstdc library.
94 They are usually better supported by external
95 debuggers and profiling tools, but less efficient. The most efficient
96 factories use non-preemptive mechanisms, such as SysV's ucontexts,
97 boost's context, or our own hand-tuned implementation, that is written
98 in assembly language. This is possible because a given actor is never
99 interrupted between consecutive simcalls in SimGrid.
101 .. image:: img/design-scheduling-wallclock.svg
105 For the sake of performance, actors can be executed in parallel using several system threads which execute all user threads in
106 turn. But in our experience, this rarely leads to any performance improvement because most applications simulated on top of
107 SimGrid are fine-grained: it's often not worth simulating actors in parallel because the amount of work of each actor is too
108 small. This is because the users tend to abstract away any large computations to efficiently simulate the control flow of their
109 application. In addition, parallel simulation puts unpleasant restrictions on the user code, that must be correctly isolated.
110 For example, the existing SMPI implementation cannot be used in parallel yet.
112 .. image:: img/design-scheduling-parallel.svg
115 Parsimonious model versatility
116 ******************************
118 Another orthogonal crux of the SimGrid design is the parsimonious
119 versatility in modeling. For that, we tend to unify all resource and
120 activity kinds. As you have seen, we parallel the classical notion of
121 **computational power** with the more original **communication power** and
122 **I/O power**. Asynchronous executions are less common than the
123 asynchronous communications that proliferate in MPI but they are still
124 provided for sake of symmetry: they even prove useful to efficiently
125 simulate thread pools. Note that asynchronous mutex locking is still to be
126 added to SimGrid atm. The notion of **pstate** was introduced to model
127 the stepwise variation of computational speed depending on the DVFS,
128 and was reused to model the bootup and shutdown phases of a CPU: the
129 computational speed is 0 at these specific pstates. This pstate notion
130 was extended to represent the fact that the bandwidth provided by a
131 wifi link to a given station depends on its signal-noise ratio (SNR).
133 Further on this line, all provided resource models are very comparable
134 internally. They :ref:`rely on linear inequation systems <models-lmm>`, stating for
135 example that the sum of the computational power received by all
136 computation activities located on a given CPU cannot overpass the
137 computational power provided by this resource. This extends nicely to
138 multi-resources activities such as communications using several links,
139 and also to the so-called parallel tasks (abstract activities
140 representing a parallel execution kernel consuming both the
141 communication and computational power of a set of machines). Specific
142 coefficients are added to the linear system to reflect how the real
143 resources are shared between concurrent usages. The resulting system
144 is then solved using a max-min objective function that maximizes the
145 minimum of all shares allocated to activities. Our experience shows
146 that this approach can successfully be used for fast yet accurate
147 simulations of complex phenomena, provided that the model's
148 coefficients and constants are carefully tailored and instantiated to
154 Even if it was not in the original goals of SimGrid, the framework now
155 integrates a full-featured model-checker (dubbed MC or Mc SimGrid)
156 that can exhaustively explore all execution paths that the application
157 could experience. Conceptually, Mc SimGrid is built upon the ideas
158 presented previously. Instead of using the resource models to compute
159 the order simcall terminations, it explores every order that is
160 causally possible. In a simulation entailing only three concurrent
161 events (i.e., simcalls) A, B, and C, it will first explore the
162 scenario where the activities order is ABC, then the ACB order, then
163 BAC, then BCA, then CAB and finally CBA. Of course, the number of
164 scenarios to explore grows exponentially with the number of simcalls
165 in the simulation. Mc SimGrid leverages reduction techniques to avoid
166 re-exploring equivalent traces.
168 In practice, Mc SimGrid can be used to verify classical `safety and
170 <https://en.wikipedia.org/wiki/Linear_time_property>`_, but also
171 `communication determinism
172 <https://hal.inria.fr/hal-01953167/document>`_, a property that allows
173 more efficient solutions toward fault-tolerance. It can alleviate the
174 state space explosion problem through `Dynamic Partial Ordering
176 <https://en.wikipedia.org/wiki/Partial_order_reduction>`_ and `state
177 equality <https://hal.inria.fr/hal-01900120/document>`_.
179 Mc SimGrid is more experimental than other parts of the framework, such as SMPI that can now be used to run many full-featured
180 MPI codes out of the box, but it's constently improving.
