6 SimGrid was conceived as a tool to study distributed algorithms. Its
7 modern :ref:`S4U interface <S4U_doc>` makes it easy to assess Cloud,
8 P2P, HPC, IoT, and similar settings.
10 A typical SimGrid simulation is composed of several |Actors|_, that
11 execute user-provided functions. The actors have to explicitly use the
12 S4U interface to express their computation, communication, disk usage,
13 and other |Activities|_ so that they get reflected within the
14 simulator. These activities take place on **Resources** (|Hosts|_,
15 |Links|_, |Disks|_). SimGrid predicts the time taken by each
16 activity and orchestrates accordingly the actors waiting for the
17 completion of these activities.
19 Each actor executes a user-provided function on a simulated |Host|_
20 with which it can interact. Communications are not directly sent to
21 actors, but posted onto a |Mailbox|_ that serves as a rendezvous point
22 between communicating actors.
24 .. |Actors| replace:: **Actors**
25 .. _Actors: app_s4u.html#s4u-actor
27 .. |Activities| replace:: **Activities**
28 .. _Activities: app_s4u.html#s4u-activity
30 .. |Hosts| replace:: **Hosts**
31 .. _Hosts: app_s4u.html#s4u-host
33 .. |Links| replace:: **Links**
34 .. _Links: app_s4u.html#s4u-link
36 .. |Disks| replace:: **Disks**
37 .. _Disks: app_s4u.html#s4u-disk
39 .. |VirtualMachines| replace:: **VirtualMachines**
40 .. _VirtualMachines: app_s4u.html#s4u-virtualmachine
42 .. |Host| replace:: **Host**
43 .. _Host: app_s4u.html#s4u-host
45 .. |Link| replace:: **Link**
46 .. _Link: app_s4u.html#s4u-link
48 .. |Mailbox| replace:: **Mailbox**
49 .. _Mailbox: app_s4u.html#s4u-mailbox
51 .. |Barrier| replace:: **Barrier**
52 .. _Barrier: app_s4u.html#s4u-barrier
54 .. |ConditionVariable| replace:: **ConditionVariable**
55 .. _ConditionVariable: app_s4u.html#s4u-conditionvariable
57 .. |Mutex| replace:: **Mutex**
58 .. _Mutex: app_s4u.html#s4u-mutex
60 **In the remainder of this tutorial**, you will discover a simple yet
61 fully-functioning example of SimGrid simulation: the Master/Workers
62 application. We will detail each part of the code and the necessary
63 configuration to make it work. After this tour, several exercises
64 are proposed to let you discover some of the SimGrid features, hands
65 on the keyboard. This practical session will be given in C++, which you
66 are supposed to know beforehand.
69 Discover the Master/Workers
70 ---------------------------
72 This section introduces an example of SimGrid simulation. This
73 simple application is composed of two kinds of actors: the **master**
74 is in charge of distributing some computational tasks to a set of
75 **workers** that execute them.
77 .. image:: /tuto_s4u/img/intro.svg
80 We first present a round-robin version of this application, where the
81 master dispatches the tasks to the workers, one after the other, until
82 all tasks are dispatched. You will improve this scheme later in this tutorial.
87 Let's start with the code of the master. It is represented by the
88 *master* function below. This simple function takes at least 3
89 parameters (the number of tasks to dispatch, their computational size
90 in flops to compute, and their communication size in bytes to
91 exchange). Every parameter after the third one must be the name of a
92 host on which a worker is waiting for something to compute.
94 Then, the tasks are sent one after the other, each on a mailbox named
95 after the worker's hosts. On the other side, a given worker (which
96 code is given below) waits for incoming tasks on its
101 In the end, once all tasks are dispatched, the master dispatches
102 another task per worker, but this time with a negative amount of flops
103 to compute. Indeed, this application decided by convention, that the
104 workers should stop when encountering such a negative compute_size.
106 At the end of the day, the only SimGrid specific functions used in
107 this example are :cpp:func:`simgrid::s4u::Mailbox::by_name` and
108 :cpp:func:`simgrid::s4u::Mailbox::put`. Also, :c:macro:`XBT_INFO` is used
109 as a replacement to `printf()` or `std::cout` to ensure that the messages
110 are nicely logged along with the simulated time and actor name.
113 .. literalinclude:: ../../examples/cpp/app-masterworkers/s4u-app-masterworkers-fun.cpp
115 :start-after: master-begin
116 :end-before: master-end
118 Here comes the code of the worker actors. This function expects no
119 parameter from its vector of strings. Its code is very simple: it
120 expects messages on the mailbox that is named after its host. As long as it gets valid
121 computation requests (whose compute_amount is positive), it computes
122 this task and waits for the next one.
124 The worker retrieves its own host with
125 :cpp:func:`simgrid::s4u::this_actor::get_host`. The
126 :ref:`simgrid::s4u::this_actor <API_s4u_this_actor>`
127 namespace contains many such helping functions.
129 .. literalinclude:: ../../examples/cpp/app-masterworkers/s4u-app-masterworkers-fun.cpp
131 :start-after: worker-begin
132 :end-before: worker-end
134 Starting the Simulation
135 .......................
137 And this is it. In only a few lines, we defined the algorithm of our
138 master/workers examples.
140 That being said, an algorithm alone is not enough to define a
141 simulation: SimGrid is a library, not a program. So you need to define
142 your own ``main()`` function as follows. This function is in charge of
143 creating a SimGrid simulation engine (on line 3), register the actor
144 functions to the engine (on lines 7 and 8), load the simulated platform
145 from its description file (on line 11), map actors onto that platform
146 (on line 12) and run the simulation until its completion on line 15.
148 .. literalinclude:: ../../examples/cpp/app-masterworkers/s4u-app-masterworkers-fun.cpp
150 :start-after: main-begin
151 :end-before: main-end
154 As you can see, this also requires a platform file and a deployment
160 Platform files define the simulated platform on which the provided
161 application will take place. It contains one or several **Network
162 Zone** |api_s4u_NetZone|_ that contains both |Host|_ and |Link|_
163 Resources, as well as routing information.
165 Such files can get rather long and boring, so the example below is
166 only an excerpt of the full ``examples/platforms/small_platform.xml``
167 file. For example, most routing information is missing, and only the
168 route between the hosts Tremblay and Fafard is given. This path
169 traverses 6 links (named 4, 3, 2, 0, 1, and 8). There are several
170 examples of platforms in the archive under ``examples/platforms``.
172 .. |api_s4u_NetZone| image:: /img/extlink.png
175 .. _api_s4u_NetZone: app_s4u.html#s4u-netzone
177 .. |api_s4u_Link| image:: /img/extlink.png
180 .. _api_s4u_Link: app_s4u.html#s4u-link
182 .. literalinclude:: ../../examples/platforms/small_platform.xml
184 :lines: 1-10,12-20,56-62,192-
185 :caption: (excerpts of the small_platform.xml file)
190 Deployment files specify the execution scenario: it lists the actors
191 that should be started, along with their parameters. In the following
192 example, we start 6 actors: one master and 5 workers.
194 .. literalinclude:: ../../examples/cpp/app-masterworkers/s4u-app-masterworkers_d.xml
200 This time, we have all parts: once the program is compiled, we can
201 execute it as follows. Note how the XBT_INFO() requests turned into
202 informative messages.
204 .. "WARNING: non-whitespace stripped by dedent" is expected here as we remove the $ marker this way
206 .. literalinclude:: ../../examples/cpp/app-masterworkers/s4u-app-masterworkers.tesh
208 :start-after: s4u-app-masterworkers-fun
209 :prepend: $$$ ./masterworkers platform.xml deploy.xml
213 Each example included in the SimGrid distribution comes with a `tesh`
214 file that presents how to start the example once compiled, along with
215 the expected output. These files are used for the automatic testing of
216 the framework but can be used to see the examples' output without
217 compiling them. See e.g. the file
218 `examples/cpp/app-masterworkers/s4u-app-masterworkers.tesh <https://framagit.org/simgrid/simgrid/-/blob/master/examples/cpp/app-masterworkers/s4u-app-masterworkers.tesh>`_.
219 Lines starting with `$` are the commands to execute;
220 lines starting with `>` are the expected output of each command, while
221 lines starting with `!` are configuration items for the test runner.
227 In this section, you will modify the example presented earlier to
228 explore the quality of the proposed algorithm. It already works, and
229 the simulation prints things, but the truth is that we have no idea of
230 whether this is a good algorithm to dispatch tasks to the workers.
231 This very simple setting raises many interesting questions:
233 .. image:: /tuto_s4u/img/question.svg
236 - Which algorithm should the master use? Or should the worker decide
239 Round Robin is not an efficient algorithm when all tasks are not
240 processed at the same speed. It would probably be more efficient
241 if the workers were asking for tasks when ready.
243 - Should tasks be grouped in batches or sent separately?
245 The workers will starve if they don't get the tasks fast
246 enough. One possibility to reduce latency would be to send tasks
247 in pools instead of one by one. But if the pools are too big, the
248 load balancing will likely get uneven, in particular when
249 distributing the last tasks.
251 - How does the quality of such an algorithm dependent on the platform
252 characteristics and on the task characteristics?
254 Whenever the input communication time is very small compared to
255 processing time and workers are homogeneous, it is likely that the
256 round-robin algorithm performs very well. Would it still hold true
257 when transfer time is not negligible? What if some tasks are
258 performed faster on some specific nodes?
260 - The network topology interconnecting the master and the workers
261 may be quite complicated. How does such a topology impact the
264 When data transfers are the bottleneck, it is likely that good
265 modeling of the platform becomes essential. The SimGrid platform
266 models are particularly handy to account for complex platform
269 - What is the best applicative topology?
271 Is a flat master-worker deployment sufficient? Should we go for a
272 hierarchical algorithm, with some forwarders taking large pools of
273 tasks from the master, each of them distributing their tasks to a
274 sub-pool of workers? Or should we introduce super-peers,
275 duplicating the master's role in a peer-to-peer manner? Do the
276 algorithms require a perfect knowledge of the network?
278 - How is such an algorithm sensitive to external workload variation?
280 What if bandwidth, latency, and computing speed can vary with no
281 warning? Shouldn't you study whether your algorithm is sensitive
282 to such load variations?
284 - Although an algorithm may be more efficient than another, how does
285 it interfere with unrelated applications executing on the same
288 **SimGrid was invented to answer such questions.** Do not believe the
289 fools saying that all you need to study such settings is a simple
290 discrete event simulator. Do you really want to reinvent the wheel,
291 debug and optimize your own tool, and validate its models against real
292 settings for ages, or do you prefer to sit on the shoulders of a
293 giant? With SimGrid, you can focus on your algorithm. The whole
294 simulation mechanism is already working.
296 Here is the visualization of a SimGrid simulation of two master-worker
297 applications (one in light gray and the other in dark gray) running in
298 concurrence and showing resource usage over a long period of time. It
299 was obtained with the Triva software.
301 .. image:: /tuto_s4u/img/result.png
307 The easiest way to take the tutorial is to use the dedicated Docker
308 image. Once you `installed Docker itself
309 <https://docs.docker.com/install/>`_, simply do the following:
311 .. code-block:: console
313 $ docker pull simgrid/tuto-s4u
314 $ docker run -it --rm --name simgrid --volume ~/simgrid-tutorial:/source/tutorial simgrid/tuto-s4u bash
316 This will start a new container with all you need to take this
317 tutorial, and create a ``simgrid-tutorial`` directory in your home on
318 your host machine that will be visible as ``/source/tutorial`` within the
319 container. You can then edit the files you want with your favorite
320 editor in ``~/simgrid-tutorial``, and compile them within the
321 container to enjoy the provided dependencies.
325 Any change to the container out of ``/source/tutorial`` will be lost
326 when you log out of the container, so don't edit the other files!
328 All needed dependencies are already installed in this container
329 (SimGrid, a C++ compiler, CMake, pajeng, and R). Vite being only
330 optional in this tutorial, it is not installed to reduce the image
333 The code template is available under ``/source/simgrid-template-s4u.git``
334 in the image. You should copy it to your working directory and
335 recompile it when you first log in:
337 .. code-block:: console
339 $ cp -r /source/simgrid-template-s4u.git/* /source/tutorial
340 $ cd /source/tutorial
344 Using your Computer Natively
345 ............................
347 To take the tutorial on your machine, you first need to :ref:`install
348 a recent version of SimGrid <install>`, a C++ compiler, and also
349 ``pajeng`` to visualize the traces. You may want to install `Vite
350 <http://vite.gforge.inria.fr/>`_ to get a first glance at the traces.
351 The provided code template requires CMake to compile. On Debian and
352 Ubuntu for example, you can get them as follows:
354 .. code-block:: console
356 $ sudo apt install simgrid pajeng cmake g++ vite
358 For R analysis of the produced traces, you may want to install R
359 and the `pajengr <https://github.com/schnorr/pajengr#installation/>`_ package.
361 .. code-block:: console
363 # install R and necessary packages
364 $ sudo apt install r-base r-cran-devtools r-cran-tidyverse
365 # install pajengr dependencies
366 $ sudo apt install git cmake flex bison
367 # install the pajengr R package
368 $ Rscript -e "library(devtools); install_github('schnorr/pajengr');"
370 An initial version of the source code is provided on framagit. This
371 template compiles with CMake. If SimGrid is correctly installed, you
372 should be able to clone the `repository
373 <https://framagit.org/simgrid/simgrid-template-s4u>`_ and recompile
374 everything as follows:
376 .. code-block:: console
378 # (exporting SimGrid_PATH is only needed if SimGrid is installed in a non-standard path)
379 $ export SimGrid_PATH=/where/to/simgrid
381 $ git clone https://framagit.org/simgrid/simgrid-template-s4u.git
382 $ cd simgrid-template-s4u/
386 If you struggle with the compilation, then you should double-check
387 your :ref:`SimGrid installation <install>`. On need, please refer to
388 the :ref:`Troubleshooting your Project Setup
389 <install_yours_troubleshooting>` section.
391 Discovering the Provided Code
392 .............................
394 Please compile and execute the provided simulator as follows:
396 .. code-block:: console
398 $ make master-workers
399 $ ./master-workers small_platform.xml master-workers_d.xml
401 For a more "fancy" output, you can use simgrid-colorizer.
403 .. code-block:: console
405 $ ./master-workers small_platform.xml master-workers_d.xml 2>&1 | simgrid-colorizer
407 If you installed SimGrid to a non-standard path, you may have to
408 specify the full path to simgrid-colorizer on the above line, such as
409 ``/opt/simgrid/bin/simgrid-colorizer``. If you did not install it at all,
410 you can find it in <simgrid_root_directory>/bin/colorize.
412 For a classical Gantt-Chart visualization, you can use `Vite
413 <http://vite.gforge.inria.fr/>`_ if you have it installed, as
414 follows. But do not spend too much time installing Vite, because there
415 is a better way to visualize SimGrid traces (see below).
417 .. code-block:: console
419 $ ./master-workers small_platform.xml master-workers_d.xml --cfg=tracing:yes --cfg=tracing/actor:yes
422 .. image:: /tuto_s4u/img/vite-screenshot.png
427 If you use an older version of SimGrid (before v3.26), you should use
428 ``--cfg=tracing/msg/process:yes`` instead of ``--cfg=tracing/actor:yes``.
430 If you want the full power to visualize SimGrid traces, you need
431 to use R. As a start, you can download this `starter script
432 <https://framagit.org/simgrid/simgrid/raw/master/docs/source/tuto_s4u/draw_gantt.R>`_
433 and use it as follows:
435 .. code-block:: console
437 $ ./master-workers small_platform.xml master-workers_d.xml --cfg=tracing:yes --cfg=tracing/actor:yes
438 $ Rscript draw_gantt.R simgrid.trace
440 It produces a ``Rplots.pdf`` with the following content:
442 .. image:: /tuto_s4u/img/Rscript-screenshot.png
446 Lab 1: Simpler Deployments
447 --------------------------
449 In the provided example, adding more workers quickly becomes a pain:
450 You need to start them (at the bottom of the file) and inform the
451 master of its availability with an extra parameter. This is mandatory
452 if you want to inform the master of where the workers are running. But
453 actually, the master does not need to have this information.
455 We could leverage the mailbox mechanism flexibility, and use a sort of
456 yellow page system: Instead of sending data to the worker running on
457 Fafard, the master could send data to the third worker. Ie, instead of
458 using the worker location (which should be filled in two locations),
459 we could use their ID (which should be filled in one location
462 This could be done with the following deployment file. It's
463 not shorter than the previous one, but it's still simpler because the
464 information is only written once. It thus follows the `DRY
465 <https://en.wikipedia.org/wiki/Don't_repeat_yourself>`_ `SPOT
466 <http://wiki.c2.com/?SinglePointOfTruth>`_ design principle.
468 .. literalinclude:: tuto_s4u/deployment1.xml
472 Copy your ``master-workers.cpp`` into ``master-workers-lab1.cpp`` and
473 add a new executable into ``CMakeLists.txt``. Then modify your worker
474 function so that it gets its mailbox name not from the name of its
475 host, but from the string passed as ``args[1]``. The master will send
476 messages to all workers based on their number, for example as follows:
480 for (int i = 0; i < tasks_count; i++) {
481 std::string worker_rank = std::to_string(i % workers_count);
482 std::string mailbox_name = std::string("worker-") + worker_rank;
483 simgrid::s4u::Mailbox* mailbox = simgrid::s4u::Mailbox::by_name(mailbox_name);
494 The mailboxes are a very powerful mechanism in SimGrid, allowing many
495 interesting application settings. They may feel unusual if you are
496 used to BSD sockets or other classical systems, but you will soon
497 appreciate their power. They are only used to match
498 communications but have no impact on the communication
499 timing. ``put()`` and ``get()`` are matched regardless of their
500 initiators' location and then the real communication occurs between
501 the involved parties.
503 Please refer to the full `Mailboxes' documentation
504 <app_s4u.html#s4u-mailbox>`_ for more details.
507 Lab 2: Using the Whole Platform
508 -------------------------------
510 It is now easier to add a new worker, but you still have to do it
511 manually. It would be much easier if the master could start the
512 workers on its own, one per available host in the platform. The new
513 deployment file should be as simple as:
515 .. literalinclude:: tuto_s4u/deployment2.xml
519 Creating the workers from the master
520 ....................................
522 For that, the master needs to retrieve the list of hosts declared in
523 the platform with :cpp:func:`simgrid::s4u::Engine::get_all_hosts`.
524 Then, the master should start the worker actors with
525 :cpp:func:`simgrid::s4u::Actor::create`.
527 ``Actor::create(name, host, func, params...)`` is a very flexible
528 function. Its third parameter is the function that the actor should
529 execute. This function can take any kind of parameter, provided that
530 you pass similar parameters to ``Actor::create()``. For example, you
531 could have something like this:
535 void my_actor(int param1, double param2, std::string param3) {
538 int main(int argc, char argv**) {
540 simgrid::s4u::ActorPtr actor;
541 actor = simgrid::s4u::Actor::create("name", simgrid::s4u::Host::by_name("the_host"),
542 &my_actor, 42, 3.14, "thevalue");
547 Master-Workers Communication
548 ............................
550 Previously, the workers got from their parameter the name of the
551 mailbox they should use. We can still do so: the master should build
552 such a parameter before using it in the ``Actor::create()`` call. The
553 master could even pass directly the mailbox as a parameter to the
556 Since we want later to study concurrent applications, it is advised to
557 use a mailbox name that is unique over the simulation even if there is
558 more than one master.
560 One possibility for that is to use the actor ID (aid) of each worker
561 as a mailbox name. The master can retrieve the aid of the newly
562 created actor with ``actor->get_pid()`` while the actor itself can
563 retrieve its own aid with ``simgrid::s4u::this_actor::get_pid()``.
564 The retrieved value is an ``aid_t``, which is an alias for ``long``.
566 Instead of having one mailbox per worker, you could also reorganize
567 completely your application to have only one mailbox per master. All
568 the workers of a given master would pull their work from the same
569 mailbox, which should be passed as a parameter to the workers.
570 This requires fewer mailboxes but prevents the master from taking
571 any scheduling decision. It depends on how you want to organize
572 your application and what you want to study with your simulator. In
573 this tutorial, that's probably not a good idea.
578 In this exercise, we reduced the amount of configuration that our
579 simulator requests. This is both a good idea and a dangerous
580 trend. This simplification is another application of the good old DRY/SPOT
581 programming principle (`Don't Repeat Yourself / Single Point Of Truth
582 <https://en.wikipedia.org/wiki/Don%27t_repeat_yourself>`_), and you
583 really want your programming artifacts to follow these software
584 engineering principles.
586 But at the same time, you should be careful in separating your
587 scientific contribution (the master/workers algorithm) and the
588 artifacts used to test it (platform, deployment, and workload). This is
589 why SimGrid forces you to express your platform and deployment files
590 in XML instead of using a programming interface: it forces a clear
591 separation of concerns between things of different nature.
593 Lab 3: Fixed Experiment Duration
594 --------------------------------
596 In the current version, the number of tasks is defined through the
597 worker arguments. Hence, tasks are created at the very beginning of
598 the simulation. Instead, have the master dispatching tasks for a
599 predetermined amount of time. The tasks must now be created on need
600 instead of beforehand.
602 Of course, usual time functions like ``gettimeofday`` will give you the
603 time on your real machine, which is pretty useless in the
604 simulation. Instead, retrieve the time in the simulated world with
605 :cpp:func:`simgrid::s4u::Engine::get_clock`.
607 You can still stop your workers with a specific task as previously,
608 or you may kill them forcefully with :cpp:func:`simgrid::s4u::Actor::kill`.
610 Anyway, the new deployment `deployment3.xml` file should thus look
613 .. literalinclude:: tuto_s4u/deployment3.xml
616 Controlling the message verbosity
617 .................................
619 Not all messages are equally informative, so you probably want to
620 change some of the ``XBT_INFO`` into ``XBT_DEBUG`` so that they are
621 hidden by default. For example, you may want to use ``XBT_INFO`` once
622 every 100 tasks and ``XBT_DEBUG`` when sending all the other tasks. Or
623 you could show only the total number of tasks processed by
624 default. You can still see the debug messages as follows:
626 .. code-block:: console
628 $ ./master-workers-lab3 small_platform.xml deployment3.xml --log=s4u_app_masterworker.thres:debug
631 Lab 4: Competing Applications
632 -----------------------------
634 It is now time to start several applications at once, with the following ``deployment4.xml`` file.
636 .. literalinclude:: tuto_s4u/deployment4.xml
639 Things happen when you do so, but it remains utterly difficult to
640 understand what's happening exactly. Even Gantt visualizations
641 contain too much information to be useful: it is impossible to
642 understand which task belongs to which application. To fix this, we
643 will categorize the tasks.
645 Instead of starting the execution in one function call only with
646 ``this_actor::execute(cost)``, you need to
647 create the execution activity, set its tracing category, and then start
648 it and wait for its completion, as follows:
652 simgrid::s4u::ExecPtr exec = simgrid::s4u::this_actor::exec_init(compute_cost);
653 exec->set_tracing_category(category);
654 // exec->start() is optional here as wait() starts the activity on need
657 You can shorten this code as follows:
661 simgrid::s4u::this_actor::exec_init(compute_cost)->set_tracing_category(category)->wait();
663 Visualizing the result
664 .......................
666 vite is not enough to understand the situation, because it does not
667 deal with categorization. This time, you absolutely must switch to R,
668 as explained on `this page
669 <https://simgrid.org/contrib/R_visualization.html>`_.
673 Include here the minimal setting to view something in R.
676 Lab 5: Better Scheduling
677 ------------------------
679 You don't need a very advanced visualization solution to notice that
680 round-robin is completely suboptimal: most of the workers keep waiting
681 for more work. We will move to a First-Come First-Served mechanism
684 For that, your workers should explicitly request work with a
685 message sent to a channel that is specific to their master. The name
686 of that private channel can be the one used to categorize the
687 executions, as it is already specific to each master.
689 The master should serve in a round-robin manner the requests it
690 receives until the time is up. Changing the communication schema can
691 be a bit hairy, but once it works, you will see that such as simple
692 FCFS schema allows one to double the number of tasks handled over time
693 here. Things may be different with another platform file.
698 From this, many things can easily be added. For example, you could:
700 - Allow workers to have several pending requests to overlap
701 communication and computations as much as possible. Non-blocking
702 communication will probably become handy here.
703 - Add a performance measurement mechanism, enabling the master to make smart scheduling choices.
704 - Test your code on other platforms, from the ``examples/platforms``
705 directory in your archive.
707 What is the largest number of tasks requiring 50e6 flops and 1e5
708 bytes that you manage to distribute and process in one hour on
710 - Optimize not only for the number of tasks handled but also for the
711 total energy dissipated.
712 - And so on. If you come up with a nice extension, please share
713 it with us so that we can extend this tutorial.
718 This tutorial is now terminated. You could keep reading the online documentation and
719 tutorials, or you could head up to the :ref:`example section <s4u_examples>` to read some code.
723 Things to improve in the future:
725 - Propose equivalent exercises and skeleton in java (and Python once we have a python binding).
727 .. LocalWords: SimGrid