smpirun -wrapper valgrind ...other args...
smpirun -wrapper "gdb --args" --cfg=contexts/factory:thread ...other args...
- Some shortcuts are available:
- ``-gdb`` is equivalent to ``-wrapper "gdb --args" -keep-temps``, to run within gdb debugger
- ``-lldb`` is equivalent to ``-wrapper "lldb --" -keep-temps``, to run within lldb debugger
- ``-vgdb`` is equivalent to ``-wrapper "valgrind --vgdb=yes --vgdb-error=0"
- -keep-temps``, to run within valgrind and allow to attach a debugger
+
+Some shortcuts are available:
+
+- ``-gdb`` is equivalent to ``-wrapper "gdb --args" -keep-temps``, to run within gdb debugger
+- ``-lldb`` is equivalent to ``-wrapper "lldb --" -keep-temps``, to run within lldb debugger
+- ``-vgdb`` is equivalent to ``-wrapper "valgrind --vgdb=yes --vgdb-error=0" -keep-temps``,
+ to run within valgrind and allow to attach a debugger
To help locate bottlenecks and largest allocations in the simulated application,
the -analyze flag can be passed to smpirun. It will activate
:ref:`smpi/display-timing<cfg=smpi/display-timing>` and
-:ref:`smpi/display-allocs<cfg=display-allocs>` options and provide hints
+:ref:`smpi/display-allocs<cfg=smpi/display-allocs>` options and provide hints
at the end of execution.
-SMPI will also report MPI handle (MPI_Comm, Request, Datatype) leaks at the end
-of execution. This can help identify memory leaks that can trigger
+SMPI will also report MPI handle (Comm, Request, Op, Datatype...) leaks
+at the end of execution. This can help identify memory leaks that can trigger
crashes and slowdowns.
By default it only displays the number of leaked items detected.
Option :ref:`smpi/list-leaks:n<cfg=smpi/list-leaks>` can be used to display the
n first leaks encountered and their type. To get more information, running smpirun
-with -wrapper "valgrind --leak-check=full --track-origins=yes" should show
+with ``-wrapper "valgrind --leak-check=full --track-origins=yes"`` should show
the exact origin of leaked handles.
Known issue : MPI_Cancel may trigger internal leaks within SMPI.
<https://framagit.org/simgrid/simgrid/tree/master/include/smpi/smpi.h>`_
in your version of SimGrid, between two lines containing the ``FIXME``
marker. If you really miss a feature, please get in touch with us: we
-can guide you though the SimGrid code to help you implementing it, and
+can guide you through the SimGrid code to help you implementing it, and
we'd be glad to integrate your contribution to the main project.
.. _SMPI_what_globals:
iterations. These samples are done per processor with
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.
+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
+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.
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>`_
error: unknown type name 'useconds_t'
.....................................
-Try to add ``-D_GNU_SOURCE`` to your compilation line to get ride
+Try to add ``-D_GNU_SOURCE`` to your compilation line to get rid
of that error.
The reason is that SMPI provides its own version of ``usleep(3)``