Copyright (C) 1984, 1989-1990, 2000-2015 Free Software Foundation, Inc.
Copyright (C) 2003-2021. The SimGrid team.
License: GPL-3+ and LGPL-2.1
-Comment: Generated with the Bison processor generator (which is GPL-3+) using SimGrid configuration files (that are LGPL-2.1)
+Comment: Generated with the Bison processor generator (which is GPL-3+) using SimGrid configuration files (that are LGPL-2.1)
Files: src/include/catch.hpp
Copyright:
- Copyright (c) 2018 Two Blue Cubes Ltd.
+ Copyright (c) 2018 Two Blue Cubes Ltd.
License: BSL-1.0
Files: src/include/xxhash.hpp
SimGrid4 will follow the these rules:
- - filenames are unique in the whole project
+ - filenames are unique in the whole project
(because of a bug in Sonar coverage computation)
C++
- fields, methods and variables are in snake_case()
- variables and functions are in snake_case()
- typedefs do not hide the pointers, i.e. * must be explicit
char* sg_host_get_name(sg_host_t* host);
-
+
This is different from the old convention (described below), that
should not be used in S4U and its bindings, nor in the kernel.
# Welcome to the SimGrid project!
-SimGrid is a scientific instrument to study the behavior of
+SimGrid is a scientific instrument to study the behavior of
large-scale distributed systems such as Grids, Clouds, HPC or P2P
-systems. It can be used to evaluate heuristics, prototype applications
+systems. It can be used to evaluate heuristics, prototype applications
or even assess legacy MPI applications.
## Installation
```
## More information
-[Online documentation](https://simgrid.org/doc/latest/) or
+[Online documentation](https://simgrid.org/doc/latest/) or
[local version](docs/source).
-You can also ask your questions, or simply discuss with other users on
+You can also ask your questions, or simply discuss with other users on
to the [SimGrid mattermost](https://framateam.org/simgrid/channels/town-square)
or on the #simgrid IRC channel of the oftc network.
Last, the main development of SimGrid is done on [Framagit](https://framagit.org/simgrid/simgrid/),
-but we also maintain a [GitHub mirror](https://github.com/simgrid/simgrid/) and an [Inria GitLab mirror](https://gitlab.inria.fr/simgrid/simgrid),
+but we also maintain a [GitHub mirror](https://github.com/simgrid/simgrid/) and an [Inria GitLab mirror](https://gitlab.inria.fr/simgrid/simgrid),
Thanks for using our software. Please do great things with it and tell
the world about it. Tell us, too, because we love to have positive
slides</a> from the SimGrid's website. You may find more up-to-date
material on the
<a href="http://people.irisa.fr/Martin.Quinson/blog/SimGrid/">blog of
-Martin Quinson</a>.
+Martin Quinson</a>.
Another great source of inspiration can be found in the @ref s4u_examples.
mechanisms (pthread_mutexes in C or the synchronized keyword in Java).
This is because the SimGrid kernel locks all processes and unlock them
one after the other when they are supposed to run, until they give the
-control back in their simcall. If one of them gets locked by the OS
+control back in their simcall. If one of them gets locked by the OS
before returning the control to the kernel, that's definitively a
deadlock.
Your commit message should follow the git habits, explained in this
<a href="http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html">blog
-post</a>, or in the
+post</a>, or in the
<a href="https://github.com/atom/atom/blob/master/CONTRIBUTING.md#git-commit-messages">
git styleguide of Atom</a>.
-
+
@subsection uhood_tech_inside_codstand Automatically Enforcing our Coding Standards
-
+
If you plan to commit code to the SimGrid project, you definitely need
to install the relevant tool to ensure that your changes follow our
coding standards:
which valgrind does not really love).
All this is configured with:
- cmake -Denable_model-checking=OFF
- -Denable_mallocators=OFF
- -Denable_compile_optimizations=OFF .
+ cmake -Denable_model-checking=OFF
+ -Denable_mallocators=OFF
+ -Denable_compile_optimizations=OFF .
* If you break the logs, you want to define XBT_LOG_MAYDAY at the
beginning of log.h. It deactivates the whole logging mechanism,
-/*!
+/*!
@page inside_cmake Adding source files or examples
@tableofcontents
-SimGrid uses CMake which is a family of tools designed to build, test, and package software.
+SimGrid uses CMake which is a family of tools designed to build, test, and package software.
@section inside_cmake_addsrc How to add source files?
-If you want to rename, add, or delete source file(s) in the SimGrid distribution, you have to edit the
-tools/cmake/DefinePackages.cmake configuration file. Files are organized in sections, then find
-the section you are interested in and modify it.
+If you want to rename, add, or delete source file(s) in the SimGrid distribution, you have to edit the
+tools/cmake/DefinePackages.cmake configuration file. Files are organized in sections, then find
+the section you are interested in and modify it.
Once you're done, test your changes with ``make distcheck``.
@section inside_cmake_examples How to add an example?
-The first rule is that the content of examples/ must be interesting to the users. It is expected that the users will
-take one of these examples and start editing it to make it fit their needs. So, it should be self-contained,
+The first rule is that the content of examples/ must be interesting to the users. It is expected that the users will
+take one of these examples and start editing it to make it fit their needs. So, it should be self-contained,
informative, and should use only the public APIs.
-To ensure that all examples actually work as expected, every example is also used as an integration test (see
-@ref inside_tests), but you should still strive to keep the code under examples/ as informative as possible for the
+To ensure that all examples actually work as expected, every example is also used as an integration test (see
+@ref inside_tests), but you should still strive to keep the code under examples/ as informative as possible for the
users. In particular, torture test cases should be placed in teshsuite/, not examples/, so that the users don't stumble
upon them by error.
- examples/platforms/ only contains platforms descriptions in the XML format (see @ref platform for details)
- examples/deprecated/msg/ for examples using the MSG API. Here the naming convention is package-example (e.g., app-masterworker).
- examples/deprecated/simdag/ for examples using the SimDag API
- - examples/deprecated/java/ for examples using the Java bindings to the MSG API. This directory contains packages (app, async,
+ - examples/deprecated/java/ for examples using the Java bindings to the MSG API. This directory contains packages (app, async,
cloud, ...) which in turn contain individual examples. If your new example fits in an existing package, add it here,
- or create a new package otherwise.
+ or create a new package otherwise.
In each of these directories, there is a CMakeLists.txt file that has
-to be edited to include the new examples.
+to be edited to include the new examples.
Once you're done, test your changes with ``make distcheck``.
-/*!
+/*!
@page inside_release Releasing SimGrid
@section inside_release_c Releasing the main library
- Rebuild and upload the python package
- rm -rf dist/ ; python3 setup.py sdist # Build a source distrib
- test that the built distrib recompiles:
- rm -rf /tmp/pysimgrid && mkdir /tmp/pysimgrid && cp dist/simgrid-*.tar.gz /tmp/pysimgrid
+ rm -rf /tmp/pysimgrid && mkdir /tmp/pysimgrid && cp dist/simgrid-*.tar.gz /tmp/pysimgrid
(cd /tmp/pysimgrid && tar xfz simgrid*.tar.gz && cd simgrid-*/ && python3 setup.py build)
- Upload it to pypi (WARNING: you cannot modify uploaded files, ever)
twine upload dist/simgrid-*.tar.gz
- gbp import-orig ../simgrid_3.*+dfsg.orig.tar.xz
- dch -i "New upstream release" # + copy the NEWS into debian/changelog
- git mv debian/libsimgrid3.XX.install debian/libsimgrid3.XY.install
- - edit debian/control: s/simgrid3.XX/simgrid3.XY/
+ - edit debian/control: s/simgrid3.XX/simgrid3.XY/
- Update the simgrid/package.py for spack: https://gitlab.inria.fr/solverstack/spack-repo
- Update the Docker images (after pushing to the git)
- cd tools/docker && make stable && make tuto-s4u tuto-smpi tuto-mc
Release Target date: https://en.wikipedia.org/wiki/Equinox
- Bump release number to 3.X.1 in CMakeLists.txt sonar-project.properties docs/source/conf.py setup.py
- Deal with deprecations:
- - jed include/xbt/base.h: Introduce the next XBT_ATTRIB_DEPRECATED_v??? macro
+ - jed include/xbt/base.h: Introduce the next XBT_ATTRIB_DEPRECATED_v??? macro
- Kill the one for the current release and remove all code that were
mandated by the deprecated functions (both in source and headers).
- Do the possible cleanups now that these features are gone.
-Release numbering semantic:
- - 3.X is a named release.
+Release numbering semantic:
+ - 3.X is a named release.
- We have 4 named releases per year (for each equinox and solstice)
- The ChangeLog and NEWS are complete and informative
- All tests pass on all ci systems (or the workarounds are documented)
- These releases are announced to the users
- 3.X.Y where Y is even: dot release of 3.X, prerelease of 3.(X+1)
- We provide and store a source .tar.gz and a full jarfile on framagit
- - These releases are NOT announced publicly, nor really documented.
+ - These releases are NOT announced publicly, nor really documented.
The idea is to have something close to a rolling release.
- External projects can depend on dot releases to loosen their
- release process from ours, when 4 release a year is not enough
+ release process from ours, when 4 release a year is not enough
- 3.X.Y where Y is odd: git current status between two releases
- No expectations on such versions
- Example
- 3.22.4: unannounced/loosely documented stable release
- 3.22.5: git status somewhere between the release of 3.22.4 and the next one
- 3.23: Documented and announced stable release
-
+
*/
-/*!
+/*!
@page inside_tests Testing SimGrid
This page will teach you how to run the tests, selecting the ones you
<a href="https://ci.inria.fr/simgrid/">available</a>.
@verbatim
-ctest # Launch all tests
+ctest # Launch all tests
ctest -R msg # Launch only the tests which name match the string "msg"
ctest -j4 # Launch all tests in parallel, at most 4 at the same time
ctest --verbose # Display all details on what's going on
even comes with a man page. TESH ensures that the output produced by a
command perfectly matches the expected output. This is very precious
to ensure that no change modifies the timings computed by the models
-without notice.
+without notice.
To add a new integration test, you thus have 3 things to do:
examples/ and modify the cmake files as explained on this page:
@ref inside_cmake_examples. If you feel like you should write a
torture test that is not interesting to the users (because nobody
- would sanely write something similar in user code), then put it under
+ would sanely write something similar in user code), then put it under
teshsuite/ somewhere.
-
+
- <b>Write the tesh file</b>, containing the command to run, the
provided input (if any, but almost no SimGrid test provide such an
input) and the expected output. Check the tesh man page for more
#XBT_LOG_ISENABLED() macro), or the modification of the log formats
to hide the timings when they depend on the host machine.@n
The script located in <project/directory>/tools/tesh/generate_tesh can
- help you a lot in particular if the output is large (though a smaller output is preferable).
+ help you a lot in particular if the output is large (though a smaller output is preferable).
There are also example tesh files in the <project/directory>/tools/tesh/ directory, that can be useful to understand the tesh syntax.
-
+
- <b>Add your test in the cmake infrastructure</b>. For that, modify
the following file:
@verbatim
<project/directory>/teshsuite/<interface eg msg>/CMakeLists.txt
- @endverbatim
+ @endverbatim
Make sure to pick a wise name for your test. It is often useful to
check a category of tests together. The only way to do so in ctest
is to use the -R argument that specifies a regular expression that
# option --setenv bindir set the directory containing the binary
# --setenv srcdir set the directory containing the source file
# --cd set the working directory
-ADD_TEST(my-test-name ${CMAKE_BINARY_DIR}/bin/tesh
+ADD_TEST(my-test-name ${CMAKE_BINARY_DIR}/bin/tesh
--setenv bindir=${CMAKE_BINARY_DIR}/examples/my-test/
--setenv srcdir=${CMAKE_HOME_DIRECTORY}/examples/my-test/
--cd ${CMAKE_HOME_DIRECTORY}/examples/my-test/
${CMAKE_HOME_DIRECTORY}/examples/deprecated/msg/io/io.tesh
)
-@endverbatim
+@endverbatim
As usual, you must run "make distcheck" after modifying the cmake files,
to ensure that you did not forget any files in the distributed archive.
@section inside_tests_ci Continuous Integration
We use several systems to automatically test SimGrid with a large set
-of parameters, across as many platforms as possible.
+of parameters, across as many platforms as possible.
We use <a href="https://ci.inria.fr/simgrid/">Jenkins on Inria
servers</a> as a workhorse: it runs all of our tests for many
configurations. It takes a long time to answer, and it often reports
issues but when it's green, then you know that SimGrid is very fit!
We use <a href="https://ci.appveyor.com/project/mquinson/simgrid">AppVeyor</a>
-to build and somehow test SimGrid on windows.
+to build and somehow test SimGrid on windows.
@subsection inside_tests_jenkins Jenkins on the Inria CI servers
(on Jenkins) to run the script <tt>tools/jenkins/DynamicAnalysis.sh</tt>
In each case, SimGrid gets built in
-/builds/workspace/$PROJECT/build_mode/$CONFIG/label/$SERVER/build
+/builds/workspace/$PROJECT/build_mode/$CONFIG/label/$SERVER/build
with $PROJECT being for instance "SimGrid", $CONFIG "DEBUG" or
"ModelChecker" and $SERVER for instance "simgrid-fedora20-64-clang".
@verbatim
#debian/ubuntu
apt-get install gcc g++ gfortran automake cmake libboost-dev openjdk-8-jdk openjdk-8-jre libxslt-dev libxml2-dev libevent-dev libunwind-dev libdw-dev htop git python3 xsltproc libboost-context-dev
-#for dynamicanalysis:
+#for dynamicanalysis:
apt-get install jacoco libjacoco-java libns3-dev pcregrep gcovr ant lua5.3-dev sloccount
#fedora
#+ clang-devel from ports
#osx
-brew install cmake boost libunwind-headers libxslt git python3
+brew install cmake boost libunwind-headers libxslt git python3
@endverbatim
@subsection inside_tests_appveyor AppVeyor
code scanners are provided as plugin. The one for C++ is not free, but
open-source project can use it at no cost. That is what we are doing.
-Don't miss the great looking dashboard here:
+Don't miss the great looking dashboard here:
https://sonarcloud.io/dashboard?id=simgrid_simgrid
*/
/** @defgroup ROUTING_API Routing: Determining the communication paths
@brief Organize the platform to determine the links used by each communication
-@section routing_basics Basic Concepts
+@section routing_basics Basic Concepts
The purpose of the simgrid::kernel::routing module is to retrieve the
routing path between two points in a time- and space-efficient manner.
represent. This operation is clearly on the critical path of most
SimGrid simulations.
-When defining how the information is routed in the simulated network,
+When defining how the information is routed in the simulated network,
it is certainly very tempting to use a formalism somehow similar to
how it is defined on real network. One would have to define the
routing tables of each routers interconnections sub-networks, just
algorithms in the simulator. The proposed description mechanism is
thus much more convenient and efficient. In addition, it is more
expressive than the classical solution based on forwarding tables on
-each host and router.
+each host and router.
The price to pay is that this representation of networks is very
specific to SimGrid, so you will have to read further to understand
The central notion here are @b Networking @b Zones. NetZones represent
network areas in which the routing is done in an homogeneous way.
Conceptually, netzones generalize from the ideas of local networks
-(such as Ethernet switched networks) and Autonomous System. The
+(such as Ethernet switched networks) and Autonomous System. The
network as a whole is represented as a single hierarchy of netzones,
meaning that every netzone is part of another netzone (but the @c
NetRoot, which is the top-level netzone).
Please note that as it is not really intended for public use, this
module is only partially documented.
*/
-
-
-
-/**
+/**
@defgroup SD_API SimDag: Legacy handling of DAG algorithms
@brief Programming environment for DAG applications
SimDag provides functionalities to simulate parallel task scheduling
arranged in DAGs (Direct Acyclic Graphs). Only centralized algorithms
can be expressed with SimDag; consider using @ref MSG_API "MSG" for
-distributed algorithms).
+distributed algorithms).
SimDag is the oldest interface in SimGrid, even if it was temporarily
removed when the new superfast kernel was added in SimGrid v3.0. It
inter-activity dependencies are added.
@{
-
+
@defgroup SD_host_api Hosts
@brief Host management
@defgroup SD_storage_api Storages
@brief Storage management
-
+
@defgroup SD_simulation Simulation
@brief Functions to create the environment and launch the simulation
@}
*/
-
/** @addtogroup SURF_API
-
+
@section SURF_doc Surf documentation
Surf is composed several components:
- @ref SURF_simulation
- @ref SURF_lmm
- @ref SURF_callbacks
- @ref plugin_energy
-
+
*/
#surf_host_model_init_current_default() (which will give you a
CLM03 model), or similar (see @ref SURF_models).
- To initialize SURF, call
- #surf_host_model_init_current_default() or #surf_host_model_init_ptask_L07()
+ To initialize SURF, call
+ #surf_host_model_init_current_default() or #surf_host_model_init_ptask_L07()
to create the platform.
Then you can access the hosts with the @ref simgrid::s4u::Engine::get_all_hosts.
- @ref TRACE_user_variables
@{
-
+
@defgroup TRACE_category Tracing categories
@brief Functions to declare tracing categories.
@defgroup TRACE_user_variables Tracing user variables
@brief Functions to declare and define user variables associated to resources.
-
+
@}
*/
\ No newline at end of file
SimGrid comes with an extensive support to trace and register what
happens during the simulation, so that it can be either visualized or
-statistically analysed after the simulation.
+statistically analysed after the simulation.
This tracing is widely used to observe and understand the behavior of
parallel applications and distributed algorithms. Usually, this is
is just some doc valuable only at the time of writing.
This section describes the storage management under SimGrid ; nowadays
it's only usable with MSG. It relies basically on linux-like concepts.
- You also may want to have a look to its corresponding section in
+ You also may want to have a look to its corresponding section in
@ref msg_file ; access functions are organized as a POSIX-like
interface.
tedious very quickly, as it is very verbose.
Consistent with some manually managed real life routing.
3. @ref pf_routing_model_simple "Simple/fast models": those models offer fast, low memory routing
- algorithms. You should consider to use this type of model if
+ algorithms. You should consider to use this type of model if
you can make some assumptions about your network zone.
Routing in this case is more or less ignored.
Routers are naturally an important concept ns-3 since the
way routers run the packet routing algorithms is actually simulated.
SimGrid's analytical models however simply aggregate the routing time
-with the transfer time.
+with the transfer time.
So why did we incorporate routers in SimGrid? Rebuilding a graph representation
only from the route information turns out to be a very difficult task, because
information.
To express this topological information, a <b>route</b> has to be
-defined in order to declare which link is connected to a router.
+defined in order to declare which link is connected to a router.
@subsubsection pf_routing_model_shortest_path Shortest-path based models
@subsection ps_dec Defining routes
-There are currently four different ways to define routes:
+There are currently four different ways to define routes:
| Name | Description |
| ------------------------------------------------- | ----------------------------------------------------------------------------------- |
want to bypass only one default route.
For an @ref pf_tag_zoneroute "zoneroute", things are just slightly more complicated, as you have
-to give the id of the gateway which is inside the zone you want to access ...
+to give the id of the gateway which is inside the zone you want to access ...
So it looks like this:
@verbatim
| dst | yes | String | See the @c src attribute |
| gw_src | yes | String | The gateway that will be used within the src zone; this can be any @ref pf_tag_host "Host" or @ref pf_router "Router" defined within the src zone. |
| gw_dst | yes | String | Same as @c gw_src, but with the dst zone instead. |
-| symmetrical | no | YES@|NO (Default: YES) | If this route is symmetric, the opposite route (from dst to src) will also be declared implicitly. |
+| symmetrical | no | YES@|NO (Default: YES) | If this route is symmetric, the opposite route (from dst to src) will also be declared implicitly. |
#### Example ####
</zone>
@endverbatim
-@subsubsection pf_tag_route <route>
+@subsubsection pf_tag_route <route>
-The principle is the same as for
+The principle is the same as for
@ref pf_tag_zoneroute "ZoneRoute": The route contains a list of links that
-provide a path from @c src to @c dst. Here, @c src and @c dst can both be either a
-@ref pf_tag_host "host" or @ref pf_router "router". This is mostly useful for the
-@ref pf_routing_model_full "Full routing model" as well as for the
-@ref pf_routing_model_shortest_path "shortest-paths" based models (as they require
+provide a path from @c src to @c dst. Here, @c src and @c dst can both be either a
+@ref pf_tag_host "host" or @ref pf_router "router". This is mostly useful for the
+@ref pf_routing_model_full "Full routing model" as well as for the
+@ref pf_routing_model_shortest_path "shortest-paths" based models (as they require
topological information).
<link_ctn id="3"/>
</route>
@endverbatim
-@note
+@note
You must only have one link in your routes when you're using them to provide
topological information, as the routes here are simply the edges of the
(network-)graph and the employed algorithms need to know which edge connects
you say that the file trace must be used by the entity.
-#### Example ####
+#### Example ####
@verbatim
<zone id="zone0" routing="Full">
<trace_connect trace="myTrace" element="bob" kind="POWER"/>
@endverbatim
-@note
- The order here is important. @c trace_connect must come
+@note
+ The order here is important. @c trace_connect must come
after the elements @c trace and @c host, as both the host
and the trace definition must be known when @c trace_connect
is parsed; the order of @c trace and @c host is arbitrary.
could use <a href="https://gitlab.inria.fr/simgrid/platform-calibration">our
calibration scripts</a>. This leads to very good fits between the
platform, the model and the needs. The g5k.xml example resulted of
-such an effort, which also lead to <a href="https://github.com/lpouillo/topo5k/">an
+such an effort, which also lead to <a href="https://github.com/lpouillo/topo5k/">an
ongoing attempt</a> to automatically extract the SimGrid platform from
the <a href="http://grid5000.fr/">Grid'5000</a> experimental platform.
But it's hard to come up with generic models. Don't take these files
Each routing model automatically adds a loopback link for each declared host, i.e.,
a network route from the host to itself, if no such route is declared in the XML
-file. This default link has a bandwidth of 498 Mb/s, a latency of 15 microseconds,
-and is <b>not</b> shared among network flows.
+file. This default link has a bandwidth of 498 Mb/s, a latency of 15 microseconds,
+and is <b>not</b> shared among network flows.
If you want to specify the characteristics of the loopback link for a given host, you
-just have to specify a route from this host to itself with the desired characteristics
-in the XML file. This will prevent the routing model to add and use the default
+just have to specify a route from this host to itself with the desired characteristics
+in the XML file. This will prevent the routing model to add and use the default
loopback link.
@subsection pf_switch I want to describe a switch but there is no switch tag!
Actually we did not include switch tag. But when you're trying to
-simulate a switch, assuming
-fluid bandwidth models are used (which SimGrid uses by default unless
+simulate a switch, assuming
+fluid bandwidth models are used (which SimGrid uses by default unless
ns-3 or constant network models are activated), the limiting factor is
switch backplane bandwidth. So, essentially, at least from
the simulation perspective, a switch is similar to a
You have several possibilities, as usual when modeling things. If your
cabinets are homogeneous and the intercabinet network negligible for
your study, you should just create a larger cluster with all hosts at
-the same layer.
+the same layer.
In the rare case where your hosts are not homogeneous between the
cabinets, you can create your cluster completely manually. For that,
create an As using the Cluster routing, and then use one
<cabinet> for each cabinet. This cabinet tag can only be used an
-As using the Cluster routing schema, and creating
+As using the Cluster routing schema, and creating
Be warned that creating a cluster manually from the XML with
<cabinet>, <backbone> and friends is rather tedious. The
if you dig into the src/ directory. <b>But things will change during
the current Gran Refactoring leading to SimGrid 4</b>. So take the
information on this page with a grain of salt, and don't be afraid if
-things are not exactly as documented here.
+things are not exactly as documented here.
At some point, we at least extend this page to present the overall
design that we are currently pursuing for SimGrid 4.
Our futures are based on the C++ Concurrency Technical Specification
API, with a few differences:
- - The simulation kernel is single-threaded so we do not need
+ - The simulation kernel is single-threaded so we do not need
inter-thread synchronization for our futures.
- As the simulation kernel cannot block, `f.wait()` is not meaningful
simulation kernel and yield the control until the request is
fulfilled. The performance requirements are very high because
the actors usually do an inordinate amount of simcalls during the
-simulation.
+simulation.
As for real syscalls, the basic idea is to write the wanted call and
its arguments in a memory area that is specific to the actor, and
void notify_one();
void notify_all();
-
+
};
@endcode
In addition, we wrote variations of some other C++ standard library
classes (`SimulationClock`, `Mutex`, `ConditionVariable`) which work in
the simulation:
-
+
* using simulated time;
* using simcalls for synchronisation.
@endcode
-## Notes
+## Notes
[^getcompared]:
This file lists the symbols ignored in the documentation.
-It follows the RST syntax but is completely ignored by sphinx.
+It follows the RST syntax but is completely ignored by sphinx.
It is only used by find-missing, that will not report any definition linked here as missing.
# This is a bug in find-missing, as these symbols are actually documented
\fB\-replay\fR <tracefile>
Replay a trace instead of actually executing an application.
.TP
-\fB\-quiet\fR
+\fB\-quiet\fR
Reduce output verbosity. This is useful to make tests reproducible.
.TP
\fB\-version\fR
.TP
.SH SIMULATION OPTIONS
You can change many simulation parameters on command line by passing
-\fB--cfg\fR=\fIparameter\fR:\fIvalue\fR after the program name.
+\fB--cfg\fR=\fIparameter\fR:\fIvalue\fR after the program name.
A full list of the existing parameters and their meaning can be found at
https://simgrid.org/doc/latest/Configuring_SimGrid.html
Copyright (c) 2014-2021. The SimGrid Team. All rights reserved.
This program is free software; you may redistribute it and/or modify
-it under the terms of GNU LGPL (v2.1) license.
+it under the terms of GNU LGPL (v2.1) license.
.SH SEE ALSO
.B smpicc\fR(1)
.B smpicxx\fR(1)
$ ${bindir:=/usr/bin}/myprogram
-=head2 Not enforcing the expected output
+=head2 Not enforcing the expected output
By default, the commands output is matched against the one expected,
and an error is raised on discrepancy. Metacommands to change this:
=over 4
-=item Every timestamps remain separated, as it should;
+=item Every timestamps remain separated, as it should;
=item In each timestamp, the output order of processes become
reproducible: that's the lexicographical order of their name;
even if that paper does only describe models for myrinet and ethernet.
You can see in Fig 2 some results for Infiniband, for example. This model
may be outdated by now for modern infiniband, anyway, so a new
-validation would be good.
+validation would be good.
The three paramaters are defined as follows:
To determine the penalty for a communication, two values need to be calculated. First, the penalty caused by the conflict in transmission, noted ps.
-- if ∆s (i) = 1 then ps = 1.
+- if ∆s (i) = 1 then ps = 1.
- if ∆s (i) ≥ 2 and ∆e (i) ≥ 3 then ps = ∆s (i) × βs × γr
-- else, ps = ∆s (i) × βs
+- else, ps = ∆s (i) × βs
Then, the penalty caused by the conflict in reception (noted pe) should be computed as follows:
- if ∆e (i) = 1 then pe = 1
-- else, pe = Φ (e) × βe × Ω (s, e)
+- else, pe = Φ (e) × βe × Ω (s, e)
Finally, the penalty associated with the communication is:
p = max (ps ∈ s, pe)
Configuring loopback link
^^^^^^^^^^^^^^^^^^^^^^^^^
-Several network model provide an implicit loopback link to account for local
+Several network model provide an implicit loopback link to account for local
communication on a host. By default it has a 10GBps bandwidth and a null latency.
-This can be changed with ``network/loopback-lat`` and ``network/loopback-bw``
+This can be changed with ``network/loopback-lat`` and ``network/loopback-bw``
items.
.. _cfg=smpi/async-small-thresh:
8192 (in KiB), while our Chord simulation works with stacks as small
as 16 KiB, for example. You can ensure that some actors have a specific
size by simply changing the value of this configuration item before
-creating these actors. The :cpp:func:`simgrid::s4u::Engine::set_config`
+creating these actors. The :cpp:func:`simgrid::s4u::Engine::set_config`
functions are handy for that.
This *setting is ignored* when using the thread factory (because there
categorization).
- MSG or SimDag-based simulator and categorized traces (you need to
- declare categories and classify your tasks according to them)
+ declare categories and classify your tasks according to them)
.. code-block:: none
assignment). In practice, change the calls for malloc() and free() into
SMPI_SHARED_MALLOC() and SMPI_SHARED_FREE().
-SMPI provides two algorithms for this feature. The first one, called
+SMPI provides two algorithms for this feature. The first one, called
``local``, allocates one block per call to SMPI_SHARED_MALLOC()
(each call site gets its own block) ,and this block is shared
among all MPI ranks. This is implemented with the shm_* functions
If you want to have spaces in your log format, you should protect it. Otherwise, SimGrid will consider that this is a space-separated list of several parameters. But you should
-also protect it from the shell that also splits command line arguments on spaces. At the end, you should use something such as ``--log="'root.fmt:%l: [%p/%c]: %m%n'"``.
-Another option is to use the ``%e`` directive for spaces, as in ``--log=root.fmt:%l:%e[%p/%c]:%e%m%n``.
+also protect it from the shell that also splits command line arguments on spaces. At the end, you should use something such as ``--log="'root.fmt:%l: [%p/%c]: %m%n'"``.
+Another option is to use the ``%e`` directive for spaces, as in ``--log=root.fmt:%l:%e[%p/%c]:%e%m%n``.
Category appender
.................
<argument value="3000"/>
</actor>
- <!-- Carole runs on 'host3', has 1 parameter "42" in its argv and one property.
+ <!-- Carole runs on 'host3', has 1 parameter "42" in its argv and one property.
-- Use simgrid::s4u::Actor::get_property() to retrieve it.-->
<actor host="host3" function="carol">
<argument value="42"/>
<actor>
--------
-This tag starts a new actor executing the given function on a given host.
+This tag starts a new actor executing the given function on a given host.
**Parent tags:** :ref:`pf_tag_platform` (only in deployment files) |br|
and resource models. But the simulation should be parsimonious too,
to not hinder the tool's usability. SimGrid tries to provide sane
default settings along with the possibility to augment and modify
- the provided models and their default settings.
+ the provided models and their default settings.
- **scalability**: ability to deal with very large simulations. In the
number of actors, in the size of the platform, in the number of
events, or all together.
and was reused to model the bootup and shutdown phases of a CPU: the
computational speed is 0 at these specific pstates. This pstate notion
was extended to represent the fact that the bandwidth provided by a
-wifi link to a given station depends on its signal-noise ratio (SNR).
+wifi link to a given station depends on its signal-noise ratio (SNR).
Further on this line, all provided resource models are very comparable
internally. They rely on linear inequation systems, stating for
- Availability and state profiles
- Reproducible random number generation
- Command line options, in particular on the model switching
-
-
-
-
^^^^^^^^^^^^^^^^^^^^^^^^^^
Head to the corresponding `GitHub Action <https://github.com/simgrid/simgrid/actions/workflows/jarfile.yml>`_
-and pick the last green build. At the bottom of the build page, click on the ``jar-final`` artefact.
+and pick the last green build. At the bottom of the build page, click on the ``jar-final`` artefact.
Open this zip file to find the jar you need. This jar can be used under Linux, Mac OSX or Windows, as you wish.
Binary Java Troubleshooting
$ make install
.. _install_src_config:
-
+
Build Configuration
^^^^^^^^^^^^^^^^^^^
files, such as ``CMakeCache.txt``. Since Cmake also generates some
files in the tree, you may need to wipe out your complete tree and
start with a fresh one when you install new dependencies.
-
+
Another (better) solution is to :ref:`build out of the source tree
<install_cmake_outsrc>`.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Once you have the Python development headers installed as well as a
-recent version of the `pybind11 <https://pybind11.readthedocs.io/en/stable/>`
+recent version of the `pybind11 <https://pybind11.readthedocs.io/en/stable/>`
module (version at least 2.4), recompiling the Python bindings from
-the source should be as easy as:
+the source should be as easy as:
.. code-block:: console
# cd simgrid-source-tree
$ python setup.py build install
-
+
Starting with SimGrid 3.13, it should even be possible to install
simgrid without downloading the source with pip:
#!/usr/bin/env sh
exec gfortran -m32 "$@"
-
- **Design the best [Simulated] Platform for a given Application.**
Tweaking the platform file is much easier than building a new real
- platform for testing purposes. SimGrid also allows for the co-design
+ platform for testing purposes. SimGrid also allows for the co-design
of the platform and the application by modifying both of them.
- **Debug Real Applications**. With real systems, is sometimes
possible platforms that you could imagine (and more).
You just provide the application and its deployment (number of
-processes and parameters), and the model checker will
+processes and parameters), and the model checker will
explore all possible outcomes by testing all possible message
interleavings: if at some point a given process can either receive the
message A first or the message B depending on the platform
Some of these applications enjoy large user communities themselves.
.. LocalWords: SimGrid
-
<zone id="zone0" routing="Floyd">
<host id="alice" speed="1Gf" />
<host id="bob" speed="1Gf" />
-
+
<link id="l1" bandwidth="1Mbps" latency="5ms" />
<link id="l2" bandwidth="1Mbps" latency="5ms" />
</route>
</zone>
</platform>
-
+
This can be reformulated as follows to make it usable with the ns-3 binding.
There is no direct connection from alice to bob, but that's OK because ns-3
automatically routes from point to point (using
<link id="l2" bandwidth="1Mbps" latency="5ms"/>
<route src="alice" dst="r1">
- <link_ctn id="l1"/>
+ <link_ctn id="l1"/>
</route>
-
+
<route src="r1" dst="bob">
- <link_ctn id="l2"/>
+ <link_ctn id="l2"/>
</route>
</zone>
</platform>
WiFi platforms
^^^^^^^^^^^^^^
-In SimGrid, WiFi networks are modeled with WiFi zones, where a zone contains
-the access point of the WiFi network and the hosts connected to it (called
-station in the WiFi world). Links inside WiFi zones are modeled as regular
-links with a specific attribute, and these links are then added to routes
-between hosts. The main difference When using ns-3 WiFi networks is that
-the network performance is not given by the link bandwidth and latency but
-by the access point WiFi characteristics, and the distance between the access
+In SimGrid, WiFi networks are modeled with WiFi zones, where a zone contains
+the access point of the WiFi network and the hosts connected to it (called
+station in the WiFi world). Links inside WiFi zones are modeled as regular
+links with a specific attribute, and these links are then added to routes
+between hosts. The main difference When using ns-3 WiFi networks is that
+the network performance is not given by the link bandwidth and latency but
+by the access point WiFi characteristics, and the distance between the access
point and the hosts.
So, to declare a new WiFi network, simply declare a zone with the ``WIFI``
<prop id="access_point" value="alice"/>
-Afterward simply declare the hosts and routers inside the WiFi network. Remember
+Afterward simply declare the hosts and routers inside the WiFi network. Remember
that one must have the same name as declared in the property "access point".
.. code-block:: xml
<router id="alice" speed="1Gf"/>
<host id="STA0-0" speed="1Gf"/>
- <host id="STA0-1" speed="1Gf"/>
+ <host id="STA0-1" speed="1Gf"/>
Finally, close the WiFi zone.
</zone>
-The WiFi zone may be connected to another zone using a traditional link and
+The WiFi zone may be connected to another zone using a traditional link and
a zoneRoute. Note that the connection between two zones is always wired.
.. code-block:: xml
Roughly speaking, it defines the speed at which the access point is
exchanging data with all stations. It depends on its model and configuration,
and the possible values are listed for example on Wikipedia.
- |br| By default, ``mcs=3``.
+ |br| By default, ``mcs=3``.
It is a property of the WiFi zone.
* ``nss`` (Number of Spatial Streams, or `number of antennas <https://en.wikipedia.org/wiki/IEEE_802.11n-2009#Number_of_antennas>`_)
defines the amount of simultaneous data streams that the AP can sustain.
Random Number Generator
-----------------------
-It is possible to define a fixed or random seed to the ns3 random number
+It is possible to define a fixed or random seed to the ns3 random number
generator using the config tag.
.. code-block:: xml
<platform version="4.1">
<config>
<prop id = "network/model" value = "ns-3" />
- <prop id = "ns3/seed" value = "time" />
+ <prop id = "ns3/seed" value = "time" />
</config>
- ...
+ ...
</platform>
The first property defines that this platform will be used with the ns3 model.
-The second property defines the seed that will be used. Defined to ``time``
-it will use a random seed, defined to a number it will use this number as
+The second property defines the seed that will be used. Defined to ``time``
+it will use a random seed, defined to a number it will use this number as
the seed.
Limitations
* End hosts cannot have more than one interface card. So, your SimGrid hosts
should be connected to the platform through only one link. Otherwise, your
SimGrid host will be considered as a router (FIXME: is it still true?).
-
+
Our goal is to keep the ns-3 plugin of SimGrid as easy (and hopefully readable)
as possible. If the current state does not fit your needs, you should modify
this plugin, and/or create your own plugin from the existing one. If you come up
severity and their topic. There is four main concepts in SimGrid's logging mechanism:
The **category** of a message represents its topic. These categories are organized as a hierarchy, loosely corresponding to SimGrid's modules architecture. :ref:`Existing categories
-<logging_categories>` are documented online, but some of them may be disabled depending on the compilation options. Use ``--help-log-categories`` on the command line to see
+<logging_categories>` are documented online, but some of them may be disabled depending on the compilation options. Use ``--help-log-categories`` on the command line to see
the categories actually provided a given simulator.
The message **priority** represents its severity. It can be one of ``trace``, ``debug``, ``verb``, ``info``, ``warn``, ``error`` and ``critical``. Every category has a configured
Graphical and statistical logging
*********************************
-To be written. For now, see `this page <https://simgrid.org/contrib/R_visualization.html>`_.
+To be written. For now, see `this page <https://simgrid.org/contrib/R_visualization.html>`_.
Building your own logging
*************************
You can add callbacks to the existing signals to get informed of each and every even occurring in the simulator. These callbacks can be used to write logs on disk in the format that
you want. Some users did so to visualize the behavior of their simulators with `Jaeger <https://www.jaegertracing.io/>`_.
-
is not mixed with the tested application. This separation of concern
:ref:`is a must <howto_science>` for your Modeling and Simulation (M&S)
work. When XML is too limiting, you may describe your platforms using
-directly :ref:`C++ code <platform_cpp>`
+directly :ref:`C++ code <platform_cpp>`
Any simulated platform must contain **basic elements**, such as
:ref:`pf_tag_host`, :ref:`pf_tag_link`, :ref:`pf_tag_disk`, and similar.
SimGrid makes no assumption about the **routing of your platform**, so you must declare
-explicitly the network path taken between each pair of hosts.
+explicitly the network path taken between each pair of hosts.
This can be done through a flat list of :ref:`pf_tag_route` for each pair of hosts (routes
are symmetrical by default), or you may use the advanced concept of :ref:`networking zone <platform_routing>`
to efficiently express the routing of your platform.
<br/>
.. _platform_cpp:
-
+
C++ Platforms
#############
.. code-block:: cpp
auto* link = zone->create_split_duplex_link("1", "125MBps")->set_latency("24us")->seal();
-
+
zone->add_route(S1, C1, nullptr, nullptr, {{link, LinkInRoute::Direction::UP}});
.. note::
Engine will look for a function with this signature: "**void load_platform(const sg4::Engine& e)**", and
execute it. It could be an easy way to make the transition between XML and C++ if necessary.
-For more details, please refer to the cpp and CMakeLists.txt files in
+For more details, please refer to the cpp and CMakeLists.txt files in
`examples/platform <https://framagit.org/simgrid/simgrid/tree/master/examples/platforms>`_.
The code is straightforward and can be easily adapted to more complex environments thanks to the flexibility
provided by the C++ API.
-
<br/>
.. _platform_examples:
-
+
Network Topology Examples
=========================
The elements basic elements (with :ref:`pf_tag_host` and
:ref:`pf_tag_link`) are described first, and then the routes between
-any pair of hosts are explicitly given with :ref:`pf_tag_route`.
+any pair of hosts are explicitly given with :ref:`pf_tag_route`.
Any host must be given a computational speed in flops while links must
be given a latency and a bandwidth. You can write 1Gf for
-1,000,000,000 flops (full list of units in the reference guide of
-:ref:`pf_tag_host` and :ref:`pf_tag_link`).
+1,000,000,000 flops (full list of units in the reference guide of
+:ref:`pf_tag_host` and :ref:`pf_tag_link`).
Routes defined with :ref:`pf_tag_route` are symmetrical by default,
meaning that the list of traversed links from A to B is the same as
SimGrid comes with an extensive set of platforms in the
`examples/platforms <https://framagit.org/simgrid/simgrid/tree/master/examples/platforms>`_
directory that should be described here.
-
- At time t = 1, the host is turned off (a zero value means OFF)
- At time t = 2, the host is turned back on (any other value than zero means ON)
- - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off
+ - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off
again at time t = 11.
If your profile does not contain any LOOPAFTER line, then it will be executed only once and not in a repetitive way.
Another possibility is to use the
-:cpp:func:`simgrid::s4u::Host::set_state_profile()` or
+:cpp:func:`simgrid::s4u::Host::set_state_profile()` or
:cpp:func:`simgrid::s4u::Link::set_state_profile()` functions. These
functions take a profile, that can be a fixed profile exhaustively
listing the events, or something else if you wish.
manually select on which core each of the existing activity should
execute. The best solution to model this is probably to model your
4-core processor as 4 distinct hosts, and assigning the activities to
-cores by migrating them to the declared hosts. In some sense, this
+cores by migrating them to the declared hosts. In some sense, this
takes the whole Network-On-Chip idea really seriously.
Some extra complications may arise here. If you have more activities than
Modeling parallel links
***********************
-Most HPC topologies, such as fat-trees, allow parallel links (a
+Most HPC topologies, such as fat-trees, allow parallel links (a
router A and a router B can be connected by more than one link).
You might be tempted to model this configuration as follows :
<link_ctn id="link2"/>
</route>
-But that will not work, since SimGrid doesn't allow several routes for
+But that will not work, since SimGrid doesn't allow several routes for
a single `{src ; dst}` pair. Instead, what you should do is :
- Use a single route with both links (so both will be traversed
each time a message is exchanged between router A and B)
- Double the bandwidth of one link, to model the total bandwidth of
- both links used in parallel. This will make sure no combined
- communications between router A and B use more than the bandwidth
+ both links used in parallel. This will make sure no combined
+ communications between router A and B use more than the bandwidth
of two links
- - Assign the other link a `FATPIPE` sharing policy, which will allow
+ - Assign the other link a `FATPIPE` sharing policy, which will allow
several communications to use the full bandwidth of this link without
having to share it. This will model the fact that individual
communications can use at most this link's bandwidth
- - Set the latency of one of the links to 0, so that latency is only
+ - Set the latency of one of the links to 0, so that latency is only
accounted for once (since both link are traversed by each message)
So the final platform for our example becomes :
example, you can have a coordinate-based routing for the WAN parts
of your platforms, a full routing within each datacenter, and a highly
optimized routing within each cluster of the datacenter. In this
-case, determining the route between two given hosts gets
+case, determining the route between two given hosts gets
"somewhat more complex" but SimGrid still computes
these routes for you in a time- and space-efficient manner.
- **Vivaldi/Wi-Fi**: "fully-connected" zones with special characteristics.
.. _inter_zone:
-
+
Inter-zone communications
=========================
A plugin can get some additional code executed within the SimGrid
kernel, and attach the data needed by that code to the SimGrid
-objects.
+objects.
-The host load plugin in
+The host load plugin in
`src/plugins/host_load.cpp <https://framagit.org/simgrid/simgrid/tree/master/src/plugins/host_load.cpp>`_
constitutes a good introductory example. It defines a class
``HostLoad`` that is meant to be attached to each host. This class
.. cpp:class:: template<class R, class... P> simgrid::xbt::signal<R(P...)>
- A signal/slot mechanism, where you can attach callbacks to a given signal, and then fire the signal.
+ A signal/slot mechanism, where you can attach callbacks to a given signal, and then fire the signal.
The template parameter is the function signature of the signal (the return value currently ignored).
Version 3.14 (Dec 25. 2016)
---------------------------
-This version (aka, the Christmas Pi) mainly introduces internal reorganization on the way to the future SimGrid 4 version.
-These changes should be transparent to the users of the MSG, SMPI and SimDag interfaces, even if some buggy features were reworked
+This version (aka, the Christmas Pi) mainly introduces internal reorganization on the way to the future SimGrid 4 version.
+These changes should be transparent to the users of the MSG, SMPI and SimDag interfaces, even if some buggy features were reworked
while some new features were added.
Users are expected to switch to this new version at their own pace, as we do not have the manpower to do any bugfixing on the old releases.
Tom to run a simulation of HPL involving 10^6 processes... Wow. The dlopen privatization schema should even allows to run your ranks
in parallel (even if it's not well tested yet).
-On the Cloud side, we implemented multi-core VMs, which naturally acts as containers of processes;
+On the Cloud side, we implemented multi-core VMs, which naturally acts as containers of processes;
S4U, the future interface of SimGrid 4.0 also progressed quite a bit.
The Storage is currently cleaned up by Fred, and some API changes are to be expected. We are sorry but the exisiting API is so crappy that
Version 3.18 (Dec. 24 2017)
---------------------------
-This is an important version for SimGrid: MSG is now deprecated, and new projects should use S4U instead.
+This is an important version for SimGrid: MSG is now deprecated, and new projects should use S4U instead.
There is still some work to do before SimGrid 4: S4U is not ready for SimDag users yet unfortunately. This will come for sure.
Main changes in the "Ho Ho Ho! SimGrid 4 beta is coming to town" release:
* Convert almost all interesting MSG examples to S4U.
* New model: energy consumption due to the network.
* Major cleanups in the disk and storage subsystems.
- * (+ further deprecate XBT, bug fixes and doc improvement)
+ * (+ further deprecate XBT, bug fixes and doc improvement)
SimGrid 4 *may* be there by the next solstice.
Version 3.19.1 (March 22. 2018)
-------------------------------
-As you may know, we are currently refactoring SimGrid in deep.
+As you may know, we are currently refactoring SimGrid in deep.
Upcoming SimGrid4 will be really different from SimGrid3: modular, standard and extensible vs. layered, homegrown and rigid. C++ vs. C.
Our goal is to smooth this transition, with backward compatibility and automatic update paths, while still progressing toward SimGrid4.
is not finished, but it's not worse than the old one either) while Augustin completed the tutorial for MPI applications. Augustin also
added several non-blocking collectives to SMPI, even if Martin finally decided to release right before he could complete the last ones
(sorry). We continued cutting on XBT, replacing many functions and modules by their standard counterparts in C++11 or in Boost. We are
-now using Catch2 for our unit testing. These cleanups may speedup your simulations by something like 10%.
+now using Catch2 for our unit testing. These cleanups may speedup your simulations by something like 10%.
Version 3.23 (June 25. 2019)
----------------------------
Version 3.27 (March 29. 2021)
-----------------------------
-To celebrate the 1176th anniversary of the siege of Paris by Vikings in 845, we just released another version of SimGrid, the Ragnar Release.
+To celebrate the 1176th anniversary of the siege of Paris by Vikings in 845, we just released another version of SimGrid, the Ragnar Release.
Yeah, that's a stupid release name, but we already had 4 "spring release" in the past, so we needed another name.
* SMPI: can now report leaks and hint about the mallocs and kernels hindering simulation scalability
And the third front is about modernizing the model checker implementation. The current state is very difficult to work with, and we hope that once it's
simplified, we will be able to implement more efficient state space reduction techniques, and also allow more synchronization mechanism to be used in the
-model checker (for now, our dpor algorithm cannot cope with mutexes).
+model checker (for now, our dpor algorithm cannot cope with mutexes).
In parallel to these refactoring, the work on SMPI stability and robustness peacefully continued. The list of MPI applications that can now work with
absolutely no change on top of SMPI really gets impressive... Check it yourself: https://framagit.org/simgrid/SMPI-proxy-apps
* SMPI: improve error handling for incorrect advanced usages.
* Many internal cleanups and refactoring to prepare the future.
-As usual, even the full changelog is only the tip of the iceberg, given the amount of changes in the backstage.
+As usual, even the full changelog is only the tip of the iceberg, given the amount of changes in the backstage.
This release is the big one for the programmatic platform descriptions, that are now fully usable from C++. XML will not
disappear anytime soon, but it is unlikely that we continue developing it in the future. When starting a new project, you should
------------------------------
To celebrate the "Ask a stupid question" release, we wish that every user ask one question about SimGrid.
-On `Mattermost <https://framateam.org/simgrid/channels/town-square>`_,
+On `Mattermost <https://framateam.org/simgrid/channels/town-square>`_,
`Stack Overflow <https://stackoverflow.com/questions/tagged/simgrid>`_,
or using the `issues tracker <https://framagit.org/simgrid/simgrid/-/issues>`_.
.. c:macro:: XBT_LOG_EXTERNAL_CATEGORY(category)
- Make an external category (i.e., a category declared in another source file) visible from this source file.
+ Make an external category (i.e., a category declared in another source file) visible from this source file.
In each source file, at most one one category can be the default one.
.. c:macro:: XBT_LOG_EXTERNAL_DEFAULT_CATEGORY(category)
**************
As SimGrid used to be written in pure C, it used to rely on custom data containers such as dynamic arrays and dictionnaries. Nowadays, the standard library of
-C++ is used internally, but some part of the interface still rely on the old containers, that are thus still available.
+C++ is used internally, but some part of the interface still rely on the old containers, that are thus still available.
-.. warning::
+.. warning::
- You should probably not start a new project using these data structures, as we will :ref:`deprecate them from SimGrid <deprecation_policy>`
+ You should probably not start a new project using these data structures, as we will :ref:`deprecate them from SimGrid <deprecation_policy>`
as soon as possible. Better implementations exist out there anyway, in particular if you're not writting pure C code.
.. doxygentypedef:: xbt_dynar_t
Dynars as regular arrays
========================
-
+
.. doxygenfunction:: xbt_dynar_get_cpy
.. doxygenfunction:: xbt_dynar_insert_at
.. doxygenfunction:: xbt_dynar_remove_at
.. doxygenfunction:: xbt_dynar_is_empty
.. doxygenfunction:: xbt_dynar_length
.. doxygenfunction:: xbt_dynar_reset
-
+
Perl-like interface
===================
xbt_dynar_t d = xbt_dynar_new(sizeof(char*), &xbt_free_ref);
- /// Push/shift example
+ /// Push/shift example
for (int i = 0; i < NB_ELEM; i++) {
char * val = xbt_strdup("hello");
xbt_dynar_push(d, &val);
Then, the tasks are sent one after the other, each on a mailbox named
after the worker's hosts. On the other side, a given worker (which
-code is given below) waits for incoming tasks on its
+code is given below) waits for incoming tasks on its
mailbox.
Using your Computer Natively
............................
-To take the tutorial on your machine, you first need to :ref:`install
+To take the tutorial on your machine, you first need to :ref:`install
a recent version of SimGrid <install>`, a C++ compiler, and also
``pajeng`` to visualize the traces. You may want to install `Vite
<http://vite.gforge.inria.fr/>`_ to get a first glance at the traces.
we could use their ID (which should be filled in one location
only).
-This could be done with the following deployment file. It's
+This could be done with the following deployment file. It's
not shorter than the previous one, but it's still simpler because the
information is only written once. It thus follows the `DRY
<https://en.wikipedia.org/wiki/Don't_repeat_yourself>`_ `SPOT
The mailboxes are a very powerful mechanism in SimGrid, allowing many
interesting application settings. They may feel unusual if you are
used to BSD sockets or other classical systems, but you will soon
-appreciate their power. They are only used to match
+appreciate their power. They are only used to match
communications but have no impact on the communication
timing. ``put()`` and ``get()`` are matched regardless of their
initiators' location and then the real communication occurs between
The elements basic elements (with :ref:`pf_tag_host` and
:ref:`pf_tag_link`) are described first, and then the routes between
-any pair of hosts are explicitly given with :ref:`pf_tag_route`.
+any pair of hosts are explicitly given with :ref:`pf_tag_route`.
Any host must be given a computational speed in flops while links must
be given a latency and a bandwidth. You can write 1Gf for
-1,000,000,000 flops (full list of units in the reference guide of
-:ref:`pf_tag_host` and :ref:`pf_tag_link`).
+1,000,000,000 flops (full list of units in the reference guide of
+:ref:`pf_tag_host` and :ref:`pf_tag_link`).
Routes defined with :ref:`pf_tag_route` are symmetrical by default,
meaning that the list of traversed links from A to B is the same as
- Hosts are connected to only 1 router above them, while these routers
are connected to 2 routers above them (thus the ``1,2`` used as
``#uplink``).
-- Hosts have only one link to their router while every path between
+- Hosts have only one link to their router while every path between
level-1 routers and level-2 routers uses 2 parallel links. Thus the
``1,2`` used as ``link count``.
$ smpicxx -O3 gemm_mpi.cpp -o gemm
$ time smpirun -np 16 -platform cluster_crossbar.xml -hostfile cluster_hostfile --cfg=smpi/display-timing:yes --cfg=smpi/running-power:1000000000 ./gemm
-This should end quite quickly, as the size of each matrix is only 1000x1000.
+This should end quite quickly, as the size of each matrix is only 1000x1000.
But what happens if we want to simulate larger runs?
Replace the size by 2000, 3000, and try again.
The simulation time increases a lot, while there are no more MPI calls performed, only computation.
-The ``--cfg=smpi/display-timing`` option gives more details about execution
+The ``--cfg=smpi/display-timing`` option gives more details about execution
and advises using sampling if the time spent in computing loops seems too high.
-The ``--cfg=smpi/host-speed:1000000000`` option sets the speed of the processor used for
-running the simulation. Here we say that its speed is the same as one of the
-processors we are simulating (1Gf), so that 1 second of computation is injected
+The ``--cfg=smpi/host-speed:1000000000`` option sets the speed of the processor used for
+running the simulation. Here we say that its speed is the same as one of the
+processors we are simulating (1Gf), so that 1 second of computation is injected
as 1 second in the simulation.
.. code-block:: console
You may want to use sampling functions or trace replay to reduce this.
So in our case (size 3000), the simulation ran for 25 seconds, and the simulated time was 5.57s at the end.
-Computation by itself took 24 seconds, and can quickly grow with larger sizes
+Computation by itself took 24 seconds, and can quickly grow with larger sizes
(as computation is really performed, there will be variability between similar runs).
-SMPI provides sampling macros to accelerate simulation by sampling iterations
-of large computation loops, and skip computation after a certain amount of iterations,
+SMPI provides sampling macros to accelerate simulation by sampling iterations
+of large computation loops, and skip computation after a certain amount of iterations,
or when the sampling is stable enough.
The two macros only slightly differ :
- ``SMPI_SAMPLE_GLOBAL`` : the specified number of samples is produced by all processors
- ``SMPI_SAMPLE_LOCAL`` : each process executes a specified number of iterations
-So if the size of the computed part varies between processes (imbalance),
+So if the size of the computed part varies between processes (imbalance),
it's safer to use the LOCAL one.
To use one of them, replacing the external for loop of the multiply routine:
SMPI_SAMPLE_GLOBAL(int i = istart, i <= iend, ++i, 10, 0.005)
The first three parameters are the ones from the loop, while the two last ones are for sampling.
-They mean that at most 10 iterations will be performed and that the sampling phase can be exited
+They mean that at most 10 iterations will be performed and that the sampling phase can be exited
earlier if the expected stability is reached after fewer samples.
-Now run the code again with various sizes and parameters and check the time taken for the
+Now run the code again with various sizes and parameters and check the time taken for the
simulation, as well as the resulting simulated time.
.. code-block:: console
The simulation took 1.23698 seconds (after parsing and platform setup)
0.0319454 seconds were actual computation of the application
-In this case, the simulation only took 1.2 seconds, while the simulated time
+In this case, the simulation only took 1.2 seconds, while the simulated time
remained almost identical.
The computation results will obviously be altered since most computations are skipped.
With 85 processes and class C, the DT simulated benchmark will try to allocate 35GB of memory,
which may not be available on the node you are using.
-To avoid this we can simply replace the largest calls to malloc and free by calls
+To avoid this we can simply replace the largest calls to malloc and free by calls
to ``SMPI_SHARED_MALLOC`` and ``SMPI_SHARED_FREE``.
This means that all processes will share one single instance of this buffer.
As for sampling, results will be altered, and this should not be used for control structures.
And simulation should finish without swapping/crashing (Ignore the warning about the return value).
-If control structures are also problematic, you can use ``SMPI_PARTIAL_SHARED_MALLOC(size, offsets, offsetscount)``
-macro, which shares only specific parts of the structure between processes,
+If control structures are also problematic, you can use ``SMPI_PARTIAL_SHARED_MALLOC(size, offsets, offsetscount)``
+macro, which shares only specific parts of the structure between processes,
and use specific memory for the important parts.
It can be freed afterward with SMPI_SHARED_FREE.
If allocations are performed with malloc or calloc, SMPI (from version 3.25) provides the option
``--cfg=smpi/auto-shared-malloc-shared:n`` which will replace all allocations above size n bytes by
-shared allocations. The value has to be carefully selected to avoid smaller control arrays,
+shared allocations. The value has to be carefully selected to avoid smaller control arrays,
containing data necessary for the completion of the run.
Try to run the (non modified) DT example again, with values going from 10 to 100,000 to show that
too small values can cause crashes.
A useful option to identify the largest allocations in the code is ``--cfg=smpi/display-allocs:yes`` (from 3.27).
It will display at the end of a (successful) run the largest allocations and their locations, helping pinpoint the
targets for sharing, or setting the threshold for automatic ones.
-For DT, the process would be to run a smaller class of problems,
+For DT, the process would be to run a smaller class of problems,
.. code-block:: console
.. code-block:: console
$ docker image pull simgrid/tuto-mc
- $ mkdir ~/tuto-mcsimgrid # or chose another directory to share between your computer and the docker container
+ $ mkdir ~/tuto-mcsimgrid # or chose another directory to share between your computer and the docker container
$ docker run -it --rm --name mcsimgrid --volume ~/tuto-mcsimgrid:/source/tutorial simgrid/tuto-mc bash
In the container, you have access to the following directories of interest:
reports the first faulty execution it finds: it may not be the shorter possible one.
.. code-block:: console
-
+
[0.000000] [mc_ModelChecker/INFO] Counter-example execution trace:
[0.000000] [mc_ModelChecker/INFO] [(1)Tremblay (server)] iRecv(dst=(1)Tremblay (server), buff=(verbose only), size=(verbose only))
[0.000000] [mc_ModelChecker/INFO] [(2)Jupiter (client)] iSend(src=(2)Jupiter (client), buff=(verbose only), size=(verbose only))
==402== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==402== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==402== Command: ./ndet-receive-s4u small_platform.xml --cfg=model-check/replay:1;2;1;1;2;4;1;1;3;1
- ==402==
+ ==402==
[0.000000] [xbt_cfg/INFO] Configuration change: Set 'model-check/replay' to '1;2;1;1;2;4;1;1;3;1'
[0.000000] [mc_record/INFO] path=1;2;1;1;2;4;1;1;3;1
[Jupiter:client:(2) 0.000000] [example/INFO] Sending 1
[Jupiter:client:(2) 0.000000] [example/INFO] Sent!
[Tremblay:server:(1) 0.000000] /source/tutorial/ndet-receive-s4u.cpp:27: [root/CRITICAL] Assertion value_got == 3 failed
(some output ignored)
- ==402==
+ ==402==
==402== Process terminating with default action of signal 6 (SIGABRT): dumping core
==402== at 0x550FCE1: raise (raise.c:51)
==402== by 0x54F9536: abort (abort.c:79)
SimGrid can simulate the time it takes to read or write data on disk, even if the stored data is not made persistent in
any way by SimGrid. This means that your application will correctly be slowed down when doing simulated I/O, but there
-is no way to get the data stored this way.
+is no way to get the data stored this way.
We decided to not model anything beyond raw access in SimGrid because we believe that there is not single way of doing so.
We provide an example model of file system as a plugin, (sparsely) documented in :ref:`plugin_filesystem`.
- At time t = 1, the host is turned off (a zero value means OFF)
- At time t = 2, the host is turned back on (any other value than zero means ON)
- - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off
+ - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off
again at time t = 11.
If your profile does not contain any LOOPAFTER line, then it will
<link>
------
-SimGrid links usually represent one-hop network connections (see :cpp:class:`simgrid::s4u::Link`), i.e., a single wire.
-They can also be used to abstract a larger network interconnect, e.g., the entire transcontinental network, into a
+SimGrid links usually represent one-hop network connections (see :cpp:class:`simgrid::s4u::Link`), i.e., a single wire.
+They can also be used to abstract a larger network interconnect, e.g., the entire transcontinental network, into a
single element.
**Parent tags:** :ref:`pf_tag_zone` (both leaf zones and inner zones) |br|
:``id``: Name of the host. Must be unique on the whole platform.
:``speed``: Computational power (in flop/s).
- If you use DVFS, provide a comma-separated list of values for each pstate (see :ref:`howto_dvfs`).
+ If you use DVFS, provide a comma-separated list of values for each pstate (see :ref:`howto_dvfs`).
:``bw_in``: Bandwidth of the private downstream link, along with its
unit. See :ref:`pf_tag_link`.
:``bw_out``: Bandwidth of the private upstream link, along with its
:``suffix``: Each node of the cluster will be suffixed with this suffix
:``radical``: Regexp used to generate cluster nodes name.
- Syntax: "10-20" will give you 11 machines numbered from 10 to 20, "10-20;2" will give you 12 machines, one with the number 2, others numbered as before.
-
+ Syntax: "10-20" will give you 11 machines numbered from 10 to 20, "10-20;2" will give you 12 machines, one with the number 2, others numbered as before.
+
The produced number is concatenated between prefix and suffix to form machine names.
:``speed``: Same as the ``speed`` attribute of the :ref:`pf_tag_host` tag.
:``core``: Same as the ``core`` attribute of the :ref:`pf_tag_host` tag.
:``limiter_link``: Bandwidth for limiter link (if any).
This adds a specific link for each node, to set the maximum bandwidth reached when communicating in both directions at the same time.
-
+
In theory this value should be 2*bw for splitduplex links, but in reality this might be less. This value will depend heavily on the communication model, and on the cluster's hardware, so no default value can be set, this has to be measured.
-
+
More details can be obtained in `Toward Better Simulation of MPI Applications on Ethernet/TCP Networks <https://hal.inria.fr/hal-00919507/>`_
:``loopback_bw``: Bandwidth for loopback (if any). See :ref:`pf_tag_link` section for syntax/details.
If loopback_bw and loopback_lat attributes are omitted, no loopback link is created and all intra-node communication will use the main network link of the node.
-
+
The sharing policy of a loopback link is **FATPIPE** :ref:`pf_tag_link`.
:``loopback_lat``: Latency for loopback (if any). See loopback_bw for more info.
:``topology``: Network topology to use.
:``topo_parameters``: Specific parameters to pass for the topology defined in the topology tag.
For torus networks, comma-separated list of the number of nodes in each dimension of the torus.
-
+
Please refer to :ref:`platform_examples`.
c-99.me
.. note::
-
+
The router name is defined as the resulting string: prefix + clusterId + "_router" + suffix.
In this case: *my_cluster_1_router* and *my_cluster_2_router.me*.
:``prefix``: Each node of the cabinet has to have a name. This name will be prefixed with this prefix.
:``suffix``: Each node of the cabinet will be suffixed with this suffix.
:``radical``: Regexp used to generate cabinet nodes name.
- Syntax: "10-20" will give you 11 machines numbered from 10 to 20, "10-20;2" will give you 12 machines, one with the number 2, others numbered as before.
-
+ Syntax: "10-20" will give you 11 machines numbered from 10 to 20, "10-20;2" will give you 12 machines, one with the number 2, others numbered as before.
+
The produced number is concatenated between prefix and suffix to form machine names.
:``speed``: Same as the ``speed`` attribute of the :ref:`pf_tag_host` tag.
:``bw``: Bandwidth for the links between nodes and backbone (if any). See the :ref:`pf_tag_link` for syntax/details.
{% block breadcrumbs_aside %}
<li class="wy-breadcrumbs-aside">
{% if hasdoc(pagename) and pagename != "search" and pagename != "genindex" %}
- {# TODO: How to rule out all java pages?
+ {# TODO: How to rule out all java pages?
# (not re.match(pagename, "java/org/simgrid"))
# fails because re is not imported #}
-
+
<a href="{{ meta['framagit_url'] }}" class="fa fa-bitbucket"> {{ _('Edit on FramaGit') }}</a>
{% endif %}
- </li>
+ </li>
{% endblock %}
- Initialize the library with :c:macro:`MSG_init`
- Create a platform (usually by parsing a file with :cpp:func:`MSG_create_environment`)
- Register the functions that your processes are supposed to run with
- :cpp:func:`MSG_function_register` (and maybe :cpp:func:`MSG_function_register_default`)
+ :cpp:func:`MSG_function_register` (and maybe :cpp:func:`MSG_function_register_default`)
- Launch your processes from a deployment file with :cpp:func:`MSG_launch_application`
- Run the simulation with :cpp:func:`MSG_main`
.. doxygenfunction:: MSG_task_set_name
.. doxygenfunction:: MSG_task_set_priority
-
+
Mailbox Management
==================
Semaphores
----------
-
+
.. doxygentypedef:: msg_sem_t
.. doxygenfunction:: MSG_sem_acquire
.. doxygenfunction:: MSG_sem_acquire_timeout
Java bindings
*************
-This section describes jMSG, the Java API to Simgrid. This API mimics
+This section describes jMSG, the Java API to Simgrid. This API mimics
:ref:`MSG <MSG_doc>`, which is a simple yet somehow realistic interface.
The full reference documentation is provided at the end of this page.
.. code-block:: console
$ cd examples/deprecated/java
- $ java -classpath ../../simgrid.jar:. .:../../simgrid.jar app.pingpong.Main ../platforms/platform.xml
+ $ java -classpath ../../simgrid.jar:. .:../../simgrid.jar app.pingpong.Main ../platforms/platform.xml
Any SimGrid simulation (java or not) is usually constituted of several
kind of actors or processes (classes extending @c Msg.Process) that
you should read carefully MSG samples and/or documentation.
- Something has crashed in the C part. Okay, here comes the tricky
thing. It happens mainly for 2 reasons:
-
+
- When something goes wrong in your simulation, sometimes the C part stops
because you used SimGrid incorrectly, and JNI bindings are not fond of that.
It means that you'll have something that looks ugly, but you should be able
settings.
Since v3.20 (June 2018), S4U is the way to go for long-term
-projects. It is feature complete, but may still evolve slightly in
+projects. It is feature complete, but may still evolve slightly in
future releases. It can already be used to do everything that can be
done in SimGrid, but you may have to adapt your code in future
releases. When this happens, compiling your code will produce
deprecation warnings for 4 releases (one year) before the removal of
-the old symbols.
+the old symbols.
If you want an API that will never ever evolve in the future, you
-should use the :ref:`deprecated MSG API <MSG_doc>` instead.
+should use the :ref:`deprecated MSG API <MSG_doc>` instead.
Main Concepts
*************
**********
Activities represent the actions that consume a resource, such as a
-:ref:`Comm <API_s4u_Comm>` that consumes the *transmitting power* of
+:ref:`Comm <API_s4u_Comm>` that consumes the *transmitting power* of
:ref:`Link <API_s4u_Link>` resources, or an :ref:`Exec <API_s4u_Exec>`
that consumes the *computing power* of :ref:`Host <API_s4u_Host>` resources.
See also the :ref:`full API <API_s4u_Activity>` below.
Every kind of activity can be asynchronous:
- - :ref:`s4u::CommPtr <API_s4u_Comm>` are created with
+ - :ref:`s4u::CommPtr <API_s4u_Comm>` are created with
:cpp:func:`s4u::Mailbox::put_async() <simgrid::s4u::Mailbox::put_async>` and
:cpp:func:`s4u::Mailbox::get_async() <simgrid::s4u::Mailbox::get_async>`.
- - :ref:`s4u::IoPtr <API_s4u_Io>` are created with
+ - :ref:`s4u::IoPtr <API_s4u_Io>` are created with
:cpp:func:`s4u::Disk::read_async() <simgrid::s4u::Disk::read_async>` and
:cpp:func:`s4u::Disk::write_async() <simgrid::s4u::Disk::write_async>`.
- :ref:`s4u::ExecPtr <API_s4u_Exec>` are created with
:dedent: 4
Then, you start all the communications that should occur concurrently with
-:cpp:func:`s4u::Mailbox::put_async() <simgrid::s4u::Mailbox::put_async>`.
+:cpp:func:`s4u::Mailbox::put_async() <simgrid::s4u::Mailbox::put_async>`.
Finally, the actor waits for the completion of all of them at once
-with
-:cpp:func:`s4u::Comm::wait_all() <simgrid::s4u::Comm::wait_all>`.
-
+with
+:cpp:func:`s4u::Comm::wait_all() <simgrid::s4u::Comm::wait_all>`.
+
.. literalinclude:: ../../examples/cpp/comm-waitall/s4u-comm-waitall.cpp
:language: c++
:start-after: put-begin
Activities Life cycle
=====================
-Sometimes, you want to change the setting of an activity before it even starts.
+Sometimes, you want to change the setting of an activity before it even starts.
.. todo:: write this section
.. _s4u_mailbox:
-
+
Mailboxes
*********
They are similar to many common things: The phone number, which allows
the caller to find the receiver. The Twitter hashtag, which helps
-senders and receivers to find each other. In TCP, the pair
+senders and receivers to find each other. In TCP, the pair
``{host name, host port}`` to which you can connect to find your peer.
-In HTTP, URLs through which the clients can connect to the servers.
+In HTTP, URLs through which the clients can connect to the servers.
In ZeroMQ, the queues are used to match senders and receivers.
One big difference with most of these systems is that no actor is the
A big difference with the ZeroMQ queues is that you cannot filter
on the data you want to get from the mailbox. To model such settings
in SimGrid, you'd have one mailbox per potential topic, and subscribe
-to each topic individually with a
+to each topic individually with a
:cpp:func:`get_async() <simgrid::s4u::Mailbox::get_async>` on each mailbox.
-Then, use :cpp:func:`Comm::wait_any() <simgrid::s4u::Comm::wait_any>`
+Then, use :cpp:func:`Comm::wait_any() <simgrid::s4u::Comm::wait_any>`
to get the first message on any of the mailboxes you are subscribed to.
The mailboxes are not located on the network, and you can access
The last twist is that by default in the simulator, the data starts
to be exchanged only when both the sender and the receiver are
announced (it waits until both :cpp:func:`put() <simgrid::s4u::Mailbox::put()>`
-and :cpp:func:`get() <simgrid::s4u::Mailbox::get()>` are posted).
+and :cpp:func:`get() <simgrid::s4u::Mailbox::get()>` are posted).
In TCP, since you establish connections beforehand, the data starts to
flow as soon as the sender posts it, even if the receiver did not post
-its :cpp:func:`put() <simgrid::s4u::Mailbox::put()>` yet.
+its :cpp:func:`put() <simgrid::s4u::Mailbox::put()>` yet.
To model this in SimGrid, you can declare a specific receiver to a
-given mailbox (with the function
-:cpp:func:`set_receiver() <simgrid::s4u::Mailbox::set_receiver()>`).
+given mailbox (with the function
+:cpp:func:`set_receiver() <simgrid::s4u::Mailbox::set_receiver()>`).
That way, any :cpp:func:`put() <simgrid::s4u::Mailbox::put()>`
posted to that mailbox will start as soon as possible, and the data
will already be there on the receiver host when the receiver actor
.. code-block:: cpp
- void myFunc()
+ void myFunc()
{
simgrid::s4u::MutexPtr mutex = simgrid::s4u::Mutex::create(); // Too bad we cannot use `new`
mutex->lock(); // use the mutex as a simple reference
// bla bla
- mutex->unlock();
-
+ mutex->unlock();
+
} // The mutex gets automatically freed because the only existing reference gets out of scope
Note that Mailboxes, Hosts, and Links are not handled through smart
.. doxygenfunction:: simgrid::s4u::Actor::get_ppid
.. doxygenfunction:: simgrid::s4u::Actor::get_properties() const
.. doxygenfunction:: simgrid::s4u::Actor::get_property(const std::string &key) const
- .. doxygenfunction:: simgrid::s4u::Actor::set_property(const std::string &key, const std::string &value)
+ .. doxygenfunction:: simgrid::s4u::Actor::set_property(const std::string &key, const std::string &value)
.. doxygenfunction:: simgrid::s4u::Actor::get_host
.. doxygenfunction:: simgrid::s4u::Actor::set_host
.. doxygenfunction:: simgrid::s4u::Actor::get_impl
.. group-tab:: Python
-
+
.. autoattribute:: simgrid.Actor.name
.. autoattribute:: simgrid.Actor.host
.. autoattribute:: simgrid.Actor.pid
.. doxygenfunction:: simgrid::s4u::Engine::register_function(const std::string &name, const kernel::actor::ActorCodeFactory &factory)
.. group-tab:: Python
-
+
.. automethod:: simgrid.Engine.load_deployment
.. automethod:: simgrid.Engine.load_platform
.. automethod:: simgrid.Engine.register_actor
.. doxygenfunction:: simgrid::s4u::Engine::run
.. group-tab:: Python
-
+
.. automethod:: simgrid.Engine.get_clock
.. automethod:: simgrid.Engine.run
idiom on mailboxes because they are internal objects to the simulation
engine. Once created, there is no way to destroy a mailbox before the end
of the simulation.
-
+
.. doxygenfunction:: simgrid::s4u::Mailbox::by_name(const std::string &name)
.. group-tab:: Python
.. code-block:: C
#include <simgrid/s4u/mailbox.h>
-
+
.. doxygentypedef:: sg_mailbox_t
.. doxygentypedef:: const_sg_mailbox_t
.. group-tab:: C
.. doxygenfunction:: sg_mailbox_set_receiver(const char *alias)
-
+
.. _API_s4u_Resource:
=========
Note that there is no DiskPtr type and that you cannot use the RAII
idiom on disks because SimGrid does not allow (yet) to create nor
- destroy resources once the simulation is started.
-
+ destroy resources once the simulation is started.
+
.. doxygenfunction:: simgrid::s4u::Disk::seal()
.. group-tab:: Python
Note that there is no HostPtr type, and that you cannot use the RAII
idiom on hosts because SimGrid does not allow (yet) to create nor
- destroy resources once the simulation is started.
+ destroy resources once the simulation is started.
.. doxygenfunction:: simgrid::s4u::Host::destroy()
.. doxygenfunction:: simgrid::s4u::Host::seal()
Note that there is no LinkPtr type and that you cannot use the RAII
idiom on hosts because SimGrid does not allow (yet) to create nor
- destroy resources once the simulation is started.
+ destroy resources once the simulation is started.
.. doxygenfunction:: simgrid::s4u::Link::seal()
Note that there is no NetZonePtr type and that you cannot use the RAII
idiom on network zones because SimGrid does not allow (yet) to create nor
- destroy resources once the simulation is started.
+ destroy resources once the simulation is started.
.. doxygenfunction:: simgrid::s4u::NetZone::seal
.. doxygenfunction:: simgrid::s4u::Comm::sendto
.. doxygenfunction:: simgrid::s4u::Comm::sendto_init
.. doxygenfunction:: simgrid::s4u::Comm::sendto_async
-
+
.. doxygenfunction:: simgrid::s4u::Comm::cancel
.. doxygenfunction:: simgrid::s4u::Comm::start
.. doxygenfunction:: simgrid::s4u::Comm::test
.. autoattribute:: simgrid.Exec.remaining_ratio
.. group-tab:: C
-
+
.. doxygenfunction:: sg_exec_set_bound(sg_exec_t exec, double bound)
.. doxygenfunction:: sg_exec_get_name(const_sg_exec_t exec)
.. doxygenfunction:: sg_exec_set_name(sg_exec_t exec, const char* name)
.. automethod:: simgrid.Exec.wait
.. group-tab:: C
-
+
.. doxygenfunction:: sg_exec_start(sg_exec_t exec)
.. doxygenfunction:: sg_exec_cancel(sg_exec_t exec);
.. doxygenfunction:: sg_exec_test(sg_exec_t exec);
- automatic (experimental): use an automatic self-benchmarking algorithm
- ompi_basic_linear: basic linear scatter
- ompi_binomial: binomial tree scatter
- - mvapich2_two_level_direct: SMP aware algorithm, with an intra-node stage (default set to mpich selector), and then a basic linear inter node stage. Use mvapich2 selector to change these to tuned algorithms for Stampede cluster.
+ - mvapich2_two_level_direct: SMP aware algorithm, with an intra-node stage (default set to mpich selector), and then a basic linear inter node stage. Use mvapich2 selector to change these to tuned algorithms for Stampede cluster.
- mvapich2_two_level_binomial: SMP aware algorithm, with an intra-node stage (default set to mpich selector), and then a binomial phase. Use mvapich2 selector to change these to tuned algorithms for Stampede cluster.
MPI_Reduce
SMPI_SAMPLE_LOCAL, and shared between all processors with
SMPI_SAMPLE_GLOBAL. Of course, none of this will work if the execution
time of your loop iteration are not stable. If some parameters have an
-incidence on the timing of a kernel, and if they are reused often
-(same kernel launched with a few different sizes during the run, for example),
-SMPI_SAMPLE_LOCAL_TAG and SMPI_SAMPLE_GLOBAL_TAG can be used, with a tag
-as last parameter, to differentiate between calls. The tag is a character
+incidence on the timing of a kernel, and if they are reused often
+(same kernel launched with a few different sizes during the run, for example),
+SMPI_SAMPLE_LOCAL_TAG and SMPI_SAMPLE_GLOBAL_TAG can be used, with a tag
+as last parameter, to differentiate between calls. The tag is a character
chain crafted by the user, with a maximum size of 128, and should include
-what is necessary to group calls of a given size together.
+what is necessary to group calls of a given size together.
This feature is demoed by the example file
`examples/smpi/NAS/ep.c <https://framagit.org/simgrid/simgrid/tree/master/examples/smpi/NAS/ep.c>`_
tracing/replay mechanism or how to use plugins written in S4U to
extend the simulator abilities.
-Another source of examples lay in the SimGrid archive, under
+Another source of examples lay in the SimGrid archive, under
`teshsuite/smpi <https://framagit.org/simgrid/simgrid/-/tree/master/examples/smpi>`_.
They are not in the ``examples`` directory because they probably don't
constitute pedagogical examples. Instead, they are intended to stress
our implementation during the tests. Some of you may be interested
anyway.
-
+
But the best source of SMPI examples is certainly the `proxy app
<https://framagit.org/simgrid/SMPI-proxy-apps>`_ external project.
Proxy apps are scale models of real, massive HPC applications: each of
framework, and you never know who have the time and knowledge to
answer your question, so please keep messages on the public mailing
list.
-
+
- If you want to chat with the community, join us on `Mattermost
<https://framateam.org/simgrid/channels/town-square>`_. Be warned
that even if many people are connected to the channel, they may not
non-french speaker are connected, we usually chat in french on
these channel, but we do switch back to english when we have a
guest.
-
+
- Asking your question on
`StackOverflow <http://stackoverflow.com/questions/tagged/simgrid>`_
is also a good idea, as this
site is very well indexed. We answer questions there too (don't
forget to use the SimGrid tag in your question so that we can see
- it), and they remain usable for the next users.
+ it), and they remain usable for the next users.
Giving back to SimGrid
----------------------
Provide fresh-eyes feedback
^^^^^^^^^^^^^^^^^^^^^^^^^^^
-We are working on the project since years. We take for granted things that are hard to infer at first, and traps we don't even see anymore.
+We are working on the project since years. We take for granted things that are hard to infer at first, and traps we don't even see anymore.
Likewise, it's hard for us to maintain the documentation uptodate with the current situation, because we don't rely on the doc when navigating the project.
-This is why your first impression as a newcomer to the project is utterly precious for us.
+This is why your first impression as a newcomer to the project is utterly precious for us.
Please make sure to write a `discovery report <https://diff.wikimedia.org/2014/03/25/seeing-through-the-eyes-of-new-technical-contributors/>`_ to enlight us.
You can send it either as a bug report, as a mail on the list or simply post it as is to the Mattermost channel.
Spread the word
^^^^^^^^^^^^^^^
-A simple way to help the SimGrid project is to **use SimGrid for your research, and say so**.
-`Cite the SimGrid framework<https://simgrid.org/publications.html>`_ in your papers and speak of it with your colleagues to spread the word.
+A simple way to help the SimGrid project is to **use SimGrid for your research, and say so**.
+`Cite the SimGrid framework<https://simgrid.org/publications.html>`_ in your papers and speak of it with your colleagues to spread the word.
The number of publications enabled by SimGrid is really important when asking for further fundings to sustain the project:
-The more you use the framework, the better for us.
+The more you use the framework, the better for us.
Add a link to the `SimGrid homepage <https://simgrid.org>`_ on your site to improve our ranking in search engines.
You can also **help us constituting an active and welcoming user community**. Answer to the question sent to the mailing lists if you can, gently pointing to
-the relevant part of the documentation on need, and help newscomers becoming part of our community too.
+the relevant part of the documentation on need, and help newscomers becoming part of our community too.
Finally, you can invite us for a talk on SimGrid to events you organize.
-We have various format, ranging from a focused `20 minute talks <http://people.irisa.fr/Martin.Quinson/blog/2020/1124/SimGrid_presentations>`_
-to a `45mn dense tutorial <http://people.irisa.fr/Martin.Quinson/blog/2012/1120/Simgrid_at_Louvain/>`_,
+We have various format, ranging from a focused `20 minute talks <http://people.irisa.fr/Martin.Quinson/blog/2020/1124/SimGrid_presentations>`_
+to a `45mn dense tutorial <http://people.irisa.fr/Martin.Quinson/blog/2012/1120/Simgrid_at_Louvain/>`_,
to a `2 hours seminar <http://people.irisa.fr/Martin.Quinson/blog/2016/0524/Experimental_methodology_for_distributed_systems>`_, or
even to `multi-days events <https://simgrid.org/tutorials.html>`_.
Note that even if most of these examples are from the same individual, several people in the team can present the project.
be reworded, a bug in the code, or any other problem. The best way to
do so is to open an issue on our
`Bug Tracker <https://framagit.org/simgrid/simgrid/issues>`_ so
-that we don't forget about it.
+that we don't forget about it.
The worst way to report such issues is to go through private emails.
These are unreliable, and we are trying to develop SimGrid openly, so
-private discussions are to be avoided if possible.
+private discussions are to be avoided if possible.
If you can provide a patch fixing the issue you report, that's even
better. If you cannot, then you need to give us a minimal working
a difficult work, which outcome is very precious to us.
Or maybe you developed an independent tool on top of SimGrid. We'd
-love helping you gaining visibility by listing it in our
-`Contrib <https://simgrid.org/contrib.html>`_.
+love helping you gaining visibility by listing it in our
+`Contrib <https://simgrid.org/contrib.html>`_.
Possible Enhancements
^^^^^^^^^^^^^^^^^^^^^
-
基于SimGrid提供的模拟器工具包, 构建一个异构多核处理器的仿真环境.
-In Liu LD, Wu YL. List Scheduling Algorithm of Dependent Tasks Based on HEFT and CPOP.
+In Liu LD, Wu YL. List Scheduling Algorithm of Dependent Tasks Based on HEFT and CPOP.
Computer Systems and Applications, 2019, 28(3): 118-125 (in Chinese).
http://www.c-s-a.org.cn/1003-3254/6807.html
-Таким образом, единственнымпакетом моделирования, соответствующимнашим требо-ваниям, является SimGrid.
-In V. Airiian, V. Korenkov and A. Nechaevskiy. Modelling LIT Cloud Infrastructure at JINR and Evaluating the Model.
-7th International Conference Distributed Computing and Grid-technologies in Science and Education, 2016 (in Russian).
+Таким образом, единственнымпакетом моделирования, соответствующимнашим требо-ваниям, является SimGrid.
+In V. Airiian, V. Korenkov and A. Nechaevskiy. Modelling LIT Cloud Infrastructure at JINR and Evaluating the Model.
+7th International Conference Distributed Computing and Grid-technologies in Science and Education, 2016 (in Russian).
http://ceur-ws.org/Vol-1787/74-79-paper-11.pdf
Os experimentos foram feitos utilizando o Simgrid, que é um simulador amplamente utilizado na avaliação de sistemas distribuı́dos.
37th Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos, 2019 (in Portuguese).
Dado [...] los modelos de rendimiento (codelets) de cada una de las rutinas computacionales [...], se podría hacer uso del simulador SimGrid para estimar el rendimiento [...].
-In D. Jesus Camara Moreno. Técnicas de optimización de rutinas paralelas de álgebra lineal en sistemas heterogéneos.
+In D. Jesus Camara Moreno. Técnicas de optimización de rutinas paralelas de álgebra lineal en sistemas heterogéneos.
PhD dissertation of the Universidad de Murcia, Spain, 2020 (in Spanish).
https://digitum.um.es/digitum/bitstream/10201/101964/1/Tesis.pdf
http://repositorio.unsa.edu.pe/bitstream/handle/UNSA/7593/ISDmaalah.pdf
SimGrid を用いて並列計算ベンチマークの演算時間，通信時間，実行時間をシミュレーションし，特に集合通信を多用するアプリケーションでは，
-In Y. Urino, K. Mizutani, T. Usuki and S. Nakamura. Parallel computing systems with wavelength routing interconnect "Optical Hub".
+In Y. Urino, K. Mizutani, T. Usuki and S. Nakamura. Parallel computing systems with wavelength routing interconnect "Optical Hub".
Research Report of the Information Processing Society of Japan, 2019 (in Japanese).
https://ipsj.ixsq.nii.ac.jp/ej/?action=pages_view_main&active_action=repository_view_main_item_detail&item_id=198402&item_no=1&page_id=13&block_id=8
cmake -DCMAKE_INSTALL_PREFIX=/usr/ -Denable_documentation=OFF -Denable_smpi=ON -Denable_compile_optimizations=ON . && \
make -j4 install
-## compile
+## compile
RUN cd /source/simgrid.git/docs/source/tuto_disk && \
cmake . &&\
make
- Link for data: `https://figshare.com/articles/dataset/Companion_of_the_SimGrid_storage_modeling_article/1175156 <https://figshare.com/articles/dataset/Companion_of_the_SimGrid_storage_modeling_article/1175156>`_
-**Disclaimer**:
+**Disclaimer**:
- The purpose of this document is to illustrate how we can
extract data from experiments and inject on SimGrid. However, the
-------
We use a special method to create non-uniform histograms to represent
-the noise in IO operations.
+the noise in IO operations.
Unable to install the library properly, I copied the important methods
here.
sg_df[sg_df$op=="write" & sg_df$flows ==1,]$method=""
ggplot(data=sg_df, aes(x=flows, y=bw, color=op)) + theme_bw() +
- geom_point(alpha=.3) +
+ geom_point(alpha=.3) +
geom_smooth(data=sg_df[sg_df$method=="loess",], color="black", method=loess,se=TRUE,fullrange=T) +
geom_smooth(data=sg_df[sg_df$method=="lm",], color="black", method=lm,se=TRUE) +
geom_errorbar(data=sg_dfd, aes(x=flows, y=mean, ymin=mean-2*se, ymax=mean+2*se),color="black",width=.6) +
- Link for paper: https://hal.inria.fr/hal-01197128
- Link for data: https://figshare.com/articles/dataset/Companion_of_the_SimGrid_storage_modeling_article/1175156
- *Disclaimer*:
+ *Disclaimer*:
- The purpose of this document is to illustrate how we can
extract data from experiments and inject on SimGrid. However, the
data shown on this page may *not* reflect the reality.
*** Scripts
We use a special method to create non-uniform histograms to represent
- the noise in IO operations.
+ the noise in IO operations.
Unable to install the library properly, I copied the important methods
here.
#+begin_src R :results output :session *R* :exports none
#' Variable-width (dagonally cut) histogram
#'
-#'
+#'
#' When constructing a histogram, it is common to make all bars the same width.
#' One could also choose to make them all have the same area.
#' These two options have complementary strengths and weaknesses; the equal-width histogram oversmooths in regions of high density, and is poor at identifying sharp peaks; the equal-area histogram oversmooths in regions of low density, and so does not identify outliers.
-#' We describe a compromise approach which avoids both of these defects. We regard the histogram as an exploratory device, rather than as an estimate of a density.
-#' @title Diagonally Cut Histogram
+#' We describe a compromise approach which avoids both of these defects. We regard the histogram as an exploratory device, rather than as an estimate of a density.
+#' @title Diagonally Cut Histogram
#' @param x is a numeric vector (the data)
#' @param a is the scaling factor, default is 5 * IQR
#' @param nbins is the number of bins, default is assigned by the Stuges method
-#' @param rx is the range used for the left of the left-most bin to the right of the right-most bin
+#' @param rx is the range used for the left of the left-most bin to the right of the right-most bin
#' @param eps used to set artificial bound on min width / max height of bins as described in Denby and Mallows (2009) on page 24.
-#' @param xlab is label for the x axis
+#' @param xlab is label for the x axis
#' @param plot = TRUE produces the plot, FALSE returns the heights, breaks and counts
#' @param lab.spikes = TRUE labels the \% of data in the spikes
-#' @return list with two elements, heights of length n and breaks of length n+1 indicating the heights and break points of the histogram bars.
+#' @return list with two elements, heights of length n and breaks of length n+1 indicating the heights and break points of the histogram bars.
#' @author Lorraine Denby, Colin Mallows
#' @references Lorraine Denby, Colin Mallows. Journal of Computational and Graphical Statistics. March 1, 2009, 18(1): 21-31. doi:10.1198/jcgs.2009.0002.
dhist<-function(x, a=5*iqr(x),
# upper and lower corners in the ecdf
ylower <- yupper - a/n
#
- cmtx <- cbind(cut(yupper, breaks = ybr), cut(yupper, breaks =
+ cmtx <- cbind(cut(yupper, breaks = ybr), cut(yupper, breaks =
ybr, left.include = TRUE), cut(ylower, breaks = ybr),
cut(ylower, breaks = ybr, left.include = TRUE))
cmtx[1, 3] <- cmtx[1, 4] <- 1
amt.txt<-0
end.y<-(-10000)
if(plot) {
- barplot(heights, abs(diff(xbr)), space = 0, density = -1, xlab =
+ barplot(heights, abs(diff(xbr)), space = 0, density = -1, xlab =
xlab, plot = TRUE, xaxt = "n",yaxt='n')
at <- pretty(xbr)
axis(1, at = at - xbr[1], labels = as.character(at))
#' Calculates the 25th and 75th quantiles given a vector x; used in function \link{dhist}.
#' @title Interquartile range
#' @param x vector
-#' @return numeric vector of length 2, with the 25th and 75th quantiles of input vector x.
+#' @return numeric vector of length 2, with the 25th and 75th quantiles of input vector x.
iqr<-function(x){
return(diff(quantile(x, c(0.25, 0.75), na.rm = TRUE)))
}
from the one in the paper. Probably, we need to further clean the
available data to obtain exaclty the same results.
- #+begin_src R :results output graphics :file fig/griffon_deg.png :exports both :width 600 :height 400 :session *R*
+ #+begin_src R :results output graphics :file fig/griffon_deg.png :exports both :width 600 :height 400 :session *R*
ggplot(data=dfc,aes(x=Jobs,y=BW, color=Operation)) + theme_bw() +
geom_point(alpha=.3) +
geom_point(data=dfrange, size=0) +
toJSON(IO_INFO, pretty = TRUE)
#+end_src
-
+
***** Write
Same for write operations.
IO_INFO[["griffon"]][["degradation"]][["write"]] = c(mean_job_1$mean, predict(model,data.frame(Jobs=seq(2,15))))
toJSON(IO_INFO, pretty = TRUE)
#+end_src
-
+
**** Modeling read/write bandwidth variability
***** Read
First, we present the histogram for read operations.
- #+begin_src R :results output graphics :file fig/griffon_read_dhist.png :exports both :width 600 :height 400 :session *R*
+ #+begin_src R :results output graphics :file fig/griffon_read_dhist.png :exports both :width 600 :height 400 :session *R*
griffon_read = df %>% filter(grepl("^Griffon", Cluster)) %>% filter(Operation == "Read") %>% select(Bwi)
dhist(1/griffon_read$Bwi)
#+end_src
***** Write
Same analysis for write operations.
- #+begin_src R :results output graphics :file fig/griffon_write_dhist.png :exports both :width 600 :height 400 :session *R*
+ #+begin_src R :results output graphics :file fig/griffon_write_dhist.png :exports both :width 600 :height 400 :session *R*
griffon_write = df %>% filter(grepl("^Griffon", Cluster)) %>% filter(Operation == "Write") %>% select(Bwi)
dhist(1/griffon_write$Bwi)
#+end_src
***** Read
- #+begin_src R :results output graphics :file fig/edel_read_dhist.png :exports both :width 600 :height 400 :session *R*
+ #+begin_src R :results output graphics :file fig/edel_read_dhist.png :exports both :width 600 :height 400 :session *R*
edel_read = df %>% filter(grepl("^Edel", Cluster)) %>% filter(Operation == "Read") %>% select(Bwi)
dhist(1/edel_read$Bwi)
#+end_src
#+end_src
***** Write
- #+begin_src R :results output graphics :file fig/edel_write_dhist.png :exports both :width 600 :height 400 :session *R*
+ #+begin_src R :results output graphics :file fig/edel_write_dhist.png :exports both :width 600 :height 400 :session *R*
edel_write = df %>% filter(grepl("^Edel", Cluster)) %>% filter(Operation == "Write") %>% select(Bwi)
dhist(1/edel_write$Bwi)
We can see that the graphics are quite similar to the ones obtained in
the real platform.
- #+begin_src R :results output graphics :file fig/simgrid_results.png :exports both :width 600 :height 400 :session *R*
+ #+begin_src R :results output graphics :file fig/simgrid_results.png :exports both :width 600 :height 400 :session *R*
sg_df = read.csv("./simgrid_disk.csv")
sg_df = sg_df %>% group_by(disk, op, flows) %>% mutate(bw=((size*flows)/elapsed)/10^6, method=if_else(disk=="edel" & op=="read", "loess", "lm"))
sg_dfd = sg_df %>% filter(flows==1 & op=="write") %>% group_by(disk, op, flows) %>% summarize(mean = mean(bw), sd = sd(bw), se=sd/sqrt(n()))
sg_df[sg_df$op=="write" & sg_df$flows ==1,]$method=""
-
+
ggplot(data=sg_df, aes(x=flows, y=bw, color=op)) + theme_bw() +
- geom_point(alpha=.3) +
+ geom_point(alpha=.3) +
geom_smooth(data=sg_df[sg_df$method=="loess",], color="black", method=loess,se=TRUE,fullrange=T) +
geom_smooth(data=sg_df[sg_df$method=="lm",], color="black", method=lm,se=TRUE) +
geom_errorbar(data=sg_dfd, aes(x=flows, y=mean, ymin=mean-2*se, ymax=mean+2*se),color="black",width=.6) +
-
(package-initialize)
(add-to-list 'package-archives
- '("gnu" . "https://elpa.gnu.org/packages/"))
+ '("gnu" . "https://elpa.gnu.org/packages/"))
(add-to-list 'package-archives
- '("melpa-stable" . "https://stable.melpa.org/packages/"))
+ '("melpa-stable" . "https://stable.melpa.org/packages/"))
(add-to-list 'package-archives
- '("melpa" . "https://melpa.org/packages/"))
+ '("melpa" . "https://melpa.org/packages/"))
(add-to-list 'load-path "/source/ox-rst.git/")
(setq package-archive-priorities '(("melpa-stable" . 100)
("melpa" . 50)
(global-set-key (kbd "C-c l") 'org-store-link)
-;; In org-mode 9 you need to have #+PROPERTY: header-args :eval never-export
-;; in the beginning or your document to tell org-mode not to evaluate every
+;; In org-mode 9 you need to have #+PROPERTY: header-args :eval never-export
+;; in the beginning or your document to tell org-mode not to evaluate every
;; code block every time you export.
(setq org-confirm-babel-evaluate nil) ;; Do not ask for confirmation all the time!!
))
(setq org-src-preserve-indentation t)
-(add-hook 'org-babel-after-execute-hook 'org-display-inline-images)
+(add-hook 'org-babel-after-execute-hook 'org-display-inline-images)
(add-hook 'org-mode-hook 'org-display-inline-images)
(add-hook 'org-mode-hook 'org-babel-result-hide-all)
SimGrid comes with an extensive set of examples, documented on this
page. Most of them only demonstrate one single feature, with some
-larger exemplars listed below.
+larger exemplars listed below.
The C++ examples can be found under examples/cpp while python examples
are in examples/python. Each such directory contains the source code (also listed
also create them directly from your code.
.. tabs::
-
+
.. example-tab:: examples/cpp/actor-create/s4u-actor-create.cpp
-
+
You create actors either:
-
+
- Directly with :cpp:func:`simgrid::s4u::Actor::create`
- From XML with :cpp:func:`simgrid::s4u::Engine::register_actor` (if your actor is a class)
or :cpp:func:`simgrid::s4u::Engine::register_function` (if your actor is a function)
and then :cpp:func:`simgrid::s4u::Engine::load_deployment`
-
+
.. example-tab:: examples/python/actor-create/actor-create.py
-
+
You create actors either:
-
+
- Directly with :py:func:`simgrid.Actor.create()`
- From XML with :py:func:`simgrid.Engine.register_actor()` and then :py:func:`simgrid.Engine.load_deployment()`
-
+
.. example-tab:: examples/c/actor-create/actor-create.c
-
+
You create actors either:
-
+
- Directly with :cpp:func:`sg_actor_create` followed by :cpp:func:`sg_actor_start`.
- From XML with :cpp:func:`simgrid_register_function` and then :cpp:func:`simgrid_load_deployment`.
-
+
.. example-tab:: examples/python/actor-create/actor-create_d.xml
-
+
The following file is used in both C++ and Python.
- **React to the end of actors:** You can attach callbacks to the end of
actors.
.. tabs::
-
+
.. example-tab:: examples/cpp/actor-exiting/s4u-actor-exiting.cpp
This example shows how to attach a callback to:
.. example-tab:: examples/c/actor-exiting/actor-exiting.c
- This example shows how to attach a callback to the end of a specific actor with
+ This example shows how to attach a callback to the end of a specific actor with
:cpp:func:`sg_actor_on_exit()`.
- **Kill actors:**
Some actors may be intended to simulate daemons that run in the background.
This example shows how to transform a regular
actor into a daemon that will be automatically killed once the simulation is over.
-
+
.. tabs::
.. example-tab:: examples/cpp/actor-daemon/s4u-actor-daemon.cpp
The stack size can be specified by default on the command line,
globally by changing the configuration with :cpp:func:`simgrid::s4u::Engine::set_config`,
or for a specific actor using :cpp:func:`simgrid::s4u::Actor::set_stacksize` before its start.
-
+
.. tabs::
.. example-tab:: examples/cpp/actor-stacksize/s4u-actor-stacksize.cpp
<s4u_ex_communication>` and the ones on :ref:`classical
synchronization objects <s4u_ex_IPC>`.
- - **Suspend and Resume actors:**
+ - **Suspend and Resume actors:**
Actors can be suspended and resumed during their executions.
.. tabs::
.. example-tab:: examples/c/actor-suspend/actor-suspend.c
- See also :cpp:func:`sg_actor_suspend()`, :cpp:func:`sg_actor_resume()`, and
+ See also :cpp:func:`sg_actor_suspend()`, :cpp:func:`sg_actor_resume()`, and
:cpp:func:`sg_actor_is_suspended()`.
- **Migrating Actors:**
- **Basic communications:**
This simple example just sends one message back and forth.
- The tesh file laying in the directory shows how to start the simulator binary, highlighting how to pass options to
+ The tesh file laying in the directory shows how to start the simulator binary, highlighting how to pass options to
the simulators (as detailed in Section :ref:`options`).
.. tabs::
- **Basic asynchronous communications:**
Illustrates how to have non-blocking communications, that are
communications running in the background leaving the process free
- to do something else during their completion.
+ to do something else during their completion.
.. tabs::
progression of a given communication for a while and then unblock it.
``is_suspended()`` can be used to retrieve whether the activity is
currently blocked or not.
-
+
.. tabs::
.. example-tab:: examples/cpp/comm-suspend/s4u-comm-suspend.cpp
:cpp:func:`simgrid::s4u::Activity::resume()` and
:cpp:func:`simgrid::s4u::Activity::is_suspended()`.
-
+
- **Waiting for all communications in a set:**
The ``wait_all()`` function is useful when you want to block until
- all activities in a given set have been completed.
-
+ all activities in a given set have been completed.
+
.. tabs::
.. example-tab:: examples/cpp/comm-waitall/s4u-comm-waitall.cpp
The ``wait_any()`` function is useful
when you want to block until one activity of the set completes, no
matter which terminates first.
-
+
.. tabs::
.. example-tab:: examples/cpp/comm-waitany/s4u-comm-waitany.cpp
.. example-tab:: examples/python/comm-waitany/comm-waitany.py
See also :py:func:`simgrid.Comm.wait_any()`.
-
+
.. example-tab:: examples/c/comm-waitany/comm-waitany.c
See also :cpp:func:`sg_comm_wait_any`.
-
+
.. _s4u_ex_execution:
Executions on the CPU
:cpp:func:`simgrid::s4u::Activity::cancel()`.
.. example-tab:: examples/python/exec-async/exec-async.py
-
+
See also :py:func:`simgrid.this_actor::exec_init()`,
:py:func:`simgrid.Activity::start()`,
:py:func:`simgrid.Activity.wait()`,
:py:func:`simgrid.Exec.get_remaining_ratio()`,
:py:func:`simgrid.this_actor.exec_async()` and
:py:func:`simgrid.Activity.cancel()`.
-
+
.. example-tab:: examples/c/exec-async/exec-async.c
See also :cpp:func:`sg_actor_exec_init()`,
:cpp:func:`sg_exec_get_remaining_ratio()`,
:cpp:func:`sg_actor_exec_async()` and
:cpp:func:`sg_exec_cancel()`,
-
+
- **Remote execution:**
You can start executions on remote hosts, or even change the host
on which they occur during their execution.
computational kernels that span over several machines, such as a
PDGEM and the other ScaLAPACK routines. Note that this only works
with the "ptask_L07" host model (``--cfg=host/model:ptask_L07``).
-
+
This example demonstrates several kinds of parallel tasks: regular
ones, communication-only (without computation), computation-only
(without communication), synchronization-only (neither
.. tabs::
.. example-tab:: examples/cpp/exec-ptask/s4u-exec-ptask.cpp
-
+
See also :cpp:func:`simgrid::s4u::this_actor::parallel_execute()`.
- **Using Pstates on a host:**
.. example-tab:: examples/cpp/io-file-system/s4u-io-file-system.cpp
- **Remote I/O:**
- I/O operations on files can also be done remotely,
+ I/O operations on files can also be done remotely,
i.e. when the accessed disk is not mounted on the caller's host.
.. tabs::
.. example-tab:: examples/cpp/platform-profile/s4u-platform-profile.cpp
- .. group-tab:: XML
+ .. group-tab:: XML
.. showfile:: examples/platforms/small_platform_profile.xml
:language: xml
.. showfile:: examples/platforms/wifi_energy.xml
:language: xml
- - **Consumption due to the CPU:**
+ - **Consumption due to the CPU:**
This example shows how to retrieve the amount of energy consumed
by the CPU during computations, and the impact of the pstate.
=======================
Tracing can be activated by various configuration options which
-are illustrated in these examples. See also the
+are illustrated in these examples. See also the
:ref:`full list of options related to tracing <tracing_tracing_options>`.
It is interesting to run the process-create example with the following
.. example-tab:: examples/c/app-token-ring/app-token-ring.c
- **Master Workers:**
- Another good old example, where one Master process has a bunch of tasks to dispatch to a set of several Worker
+ Another good old example, where one Master process has a bunch of tasks to dispatch to a set of several Worker
processes.
.. tabs::
.. showfile:: examples/c/app-masterworker/app-masterworker.c
:language: cpp
-
+
Data diffusion
--------------
- - **Bit Torrent:**
+ - **Bit Torrent:**
Classical protocol for Peer-to-Peer data diffusion.
.. tabs::
.. showfile:: examples/c/app-bittorrent/tracker.c
:language: cpp
- - **Chained Send:**
+ - **Chained Send:**
Data broadcast over a ring of processes.
.. tabs::
Distributed Hash Tables (DHT)
-----------------------------
- - **Chord Protocol**
+ - **Chord Protocol**
One of the most famous DHT protocol.
.. tabs::
This simple ping-pong example demonstrates how to use the bindings to the Network
Simulator. The most interesting is probably not the C++ files since
they are unchanged from the other simulations, but the associated files,
- such as the platform file to see how to declare a platform to be used
- with the ns-3 bindings of SimGrid and the tesh file to see how to
+ such as the platform file to see how to declare a platform to be used
+ with the ns-3 bindings of SimGrid and the tesh file to see how to
start a simulation in these settings.
.. tabs::
.. showfile:: examples/platforms/small_platform_one_link_routes.xml
:language: xml
-
+
- **wifi links**
-
+
This demonstrates how to declare a wifi zone in your platform and
how to use it in your simulation. For that, you should have a link
whose sharing policy is set to `WIFI`. Such links can have more
than one bandwidth value (separated by commas), corresponding to
the several SNR level of your wifi link.
-
+
In this case, SimGrid automatically switches to validated
performance models of wifi networks, where the time is shared
between users instead of the bandwidth for wired links (the
corresponding publication is currently being written).
-
+
If your wifi link provides more than one SNR level, you can switch
the level of a given host using
:cpp:func:`simgrid::s4u::Link::set_host_wifi_rate`. By default,
There are two tests:
-- The first one aims at validating the migration in presence of consolidated VMs
+- The first one aims at validating the migration in presence of consolidated VMs
- The second one aims at validating the robustness of the migration process (the SRC node or the DST node are turned off during the migration process)
-To switch between the first and the second tests, you should instrument Main.java (sorry for that :( )
+To switch between the first and the second tests, you should instrument Main.java (sorry for that :( )
Adsein - Thu Oct 9 18:25:39 CEST 2014
UPDATE: the second test was never used (dit it ever work?), and was removed 4 years later
----------------------------------------------------------------------
NPB-MPI is a sample MPI implementation based on NPB2.4 and NPB3.0-SER.
-This subset contains three of the original benchmarks: one in Fortran: EP;
+This subset contains three of the original benchmarks: one in Fortran: EP;
one in C: IS, as well as the DT benchmark, written in C, introduced in NPB3.2-MPI.
1. Compilation
Before compilation, one needs to check the configuration file
- 'make.def' in the config directory and modify the file if necessary.
+ 'make.def' in the config directory and modify the file if necessary.
make <benchmark-name> NPROCS=<number> CLASS=<class> \
[SUBTYPE=<type>] [VERSION=VEC]
Class E is not available for IS and DT.
- Class D for IS (Integer Sort) requires a compiler/system that
- supports the "long" type in C to be 64-bit.
-
+ Class D for IS (Integer Sort) requires a compiler/system that
+ supports the "long" type in C to be 64-bit.
+
2. Execution
The executable is named <benchmark-name>.<class>.<nprocs>
- The executable is placed in the bin subdirectory (or in the directory
- BINDIR specified in make.def, if you've defined it). The method for
+ The executable is placed in the bin subdirectory (or in the directory
+ BINDIR specified in make.def, if you've defined it). The method for
running the MPI program depends on your local system.
2 smpi_replay.txt 32 125000000000
-This launches an instance "2" that will replay file smpi_replay.txt with 32 processes, and each one of these processes
+This launches an instance "2" that will replay file smpi_replay.txt with 32 processes, and each one of these processes
will sleep for 125000000000 flops before the run.
-In order to be replayed, a deployment file must be generatedfrom this description file, and from the intended platform
-file and hostfiles. The script generate_multiple_deployment.sh can be used as such :
+In order to be replayed, a deployment file must be generatedfrom this description file, and from the intended platform
+file and hostfiles. The script generate_multiple_deployment.sh can be used as such :
./generate_multiple_deployment.sh -platform platform_file.xml -hostfile hostfile description_file deployment.xml
The output deployment file will be written in deployment.xml
-Please not that the deployment will use the hostfile in order, placing processes of the first instance using the first
+Please not that the deployment will use the hostfile in order, placing processes of the first instance using the first
node, and the ones of the following instances on the following nodes.
The actual replay can now be launched, using classic options for SMPI
previously allocated by @code{mmalloc} in @var{ptr}, reallocate the
memory to be @var{size} bytes long, possibly moving the existing
contents of memory if necessary.
-
+
@item void *mvalloc (void *@var{md}, size_t @var{size});
Like @code{mmalloc} but the resulting memory is aligned on a page boundary.
