doc/modules.doc

   1 /**
   2   \defgroup SimGrid_API  SimGrid modules */
   3
   4 /** \defgroup XBT_API      XBT
   5     \ingroup SimGrid_API
   6     \brief The core toolbox of SimGrid, containing usefull datatypes,
   7            portability support and so on.
   8
   9 */
  10
  11 /** \defgroup MSG_API      MSG
  12     \ingroup SimGrid_API
  13     \brief Simple programming environment
  14
  15       MSG was the first distributed programming environment provided within
  16       SimGrid. While almost realistic, it remains quite simple (simplistic?).
  17
  18       \section MSG_who Who should use this (and who shouldn't)
  19
  20       You should use this module if you want to study some heuristics for a
  21       given problem you don't really want to implement.
  22       If you want to use DAGs, have a look at the \ref SD_API programming
  23       environment.
  24       If you want to get a real (but experimental) implementation of your solution, have a look
  25       at the \ref GRAS_API one. If you want to study an existing MPI program,
  26       have a look at the \ref SMPI_API one. If none of those programming
  27       environments fits your needs, you may consider implementing your own
  28       directly on top of \ref SURF_API (but you probably want to contact us
  29       before).
  30 */
  31
  32
  33 /** \defgroup SIMIX_API      SIMIX
  34     \ingroup SimGrid_API
  35     \brief POSIX-like interface for building simulation
  36
  37     This is a developer-level interface that should be useful only if you
  38     plan to design a new interface for SimGrid.
  39 */
  40
  41
  42 /** \defgroup GRAS_API      GRAS
  43     \ingroup SimGrid_API
  44     \brief Realistic programming environment (Grid Reality And Simulation)
  45
  46     GRAS provides a complete API to implement distributed application on top
  47     of heterogeneous plateforms. In addition to the SimGrid implementation
  48     of this interface (allowing you to work on your application within the
  49     comfort of the simulator), an implementation suited to real platforms is
  50     also provided (allowing you to really use your application once you're
  51     done with developing it). It may still contain rought corners as
  52     GRAS is not the most used part of SimGrid, however.
  53
  54     GRAS thus constitute a complete grid application developement framework,
  55     encompassing both developer helping tools (the simulator and associated
  56     tools) and an efficient while portable execution runtime.
  57
  58     \section GRAS_who Who should use this (and who shouldn't)
  59
  60     You should use this programming environment if you want to develop real
  61     applications, ie if the final result of your work is a program which
  62     may eventually be distributed. Rember however that GRAS is
  63     considered as experimental at this point. Help would be welcomed
  64     to improve this sorry situation...
  65
  66     If you just want to study some heuristics for a given problem you don't
  67     want to implement really (ie, if your result would be a theorem), have a
  68     look at the \ref MSG_API one, or the \ref SD_API one if you need to use DAGs.
  69     If you want to study an existing MPI program, have a look at the
  70     \ref SMPI_API one.
  71     If none of those programming environments fits your needs, you may
  72     consider implementing your own directly on top of \ref SURF_API (but you
  73     probably want to contact us before).
  74 */
  75
  76 /** \defgroup AMOK_API AMOK
  77     \ingroup SimGrid_API
  78     \brief Distributed toolkit built over \ref GRAS_API (Advanced Metacomputing Overlay Kit)
  79
  80     AMOK provides several tools useful to most applications built on top of GRAS,
  81     but yet not belonging to GRAS itself. It is planned that those modules will be
  82     changed to real plugins one day, allowing users to load only the needed parts at
  83     run time. For now, they live in another library against which you should link your
  84     programs explicitly.
  85 */
  86
  87 /** \defgroup SMPI_API      SMPI
  88     \ingroup SimGrid_API
  89     \brief Programming environment for the simulation of MPI applications
  90
  91 This programming environment permits to study existing MPI application
  92 by emulating them on top of the SimGrid simulator. In other words, it
  93 will constitute an emulation solution for parallel codes. You don't
  94 even have to modify your code for that, although that may help, as
  95 detailed below.
  96
  97 \section SMPI_who Who should use SMPI (and who shouldn't)
  98
  99 You should use this programming environment of the SimGrid suite if
 100 you want to study existing MPI applications. If you want to create a
 101 distributed application, you may be interested in the \ref GRAS_API
 102 environment instead (but note that GRAS is not very actively
 103 maintained nowadays). If you want to study some heuristics for a given
 104 problem (and if your goal is to produce theorems and publications, not
 105 code), have a look at the \ref MSG_API environment, or the \ref SD_API
 106 one if you need to use DAGs. If none of those programming environments
 107 fits your needs, you may consider implementing your own directly on
 108 top of \ref SURF_API (but you probably want to contact us before).
 109
 110 \section SMPI_what What can run within SMPI?
 111
 112 You can run unmodified MPI applications (both C and Fortran) within
 113 SMPI, provided you only use MPI calls that we implemented in MPI. Our
 114 coverage of the interface is not bad, but will probably never be
 115 complete. One sided communications and I/O primitives are not targeted
 116 for now. The full list of not yet implemented functions is available
 117 in file <tt>include/smpi/smpi.h</tt> of the archive, between two lines
 118 containing the <tt>FIXME</tt> marker. If you really need a missing
 119 feature, please get in touch with us: we can guide you though the
 120 SimGrid code to help you implementing it, and we'd glad to integrate
 121 it in the main project afterward if you contribute them back.
 122
 123 \section SMPI_adapting Adapting your MPI code to the use of SMPI
 124
 125 As detailed in the reference article (available at
 126 http://hal.inria.fr/inria-00527150), you may want to adapt your code
 127 to improve the simulation performance. But these tricks may seriously
 128 hinder the result qualtity (or even prevent the app to run) if used
 129 wrongly. We assume that if you want to simulate an HPC application,
 130 you know what you are doing. Don't prove us wrong!
 131
 132 If you get short on memory (the whole app is executed on a single node
 133 when simulated), you should have a look at the SMPI_SHARED_MALLOC and
 134 SMPI_SHARED_FREE macros. It allows to share memory areas between
 135 processes. For example, matrix multiplication code may want to store
 136 the blocks on the same area. Of course, the resulting computations
 137 will useless, but you can still study the application behavior this
 138 way. Of course, if your code is data-dependent, this won't work.
 139
 140 If your application is too slow, try using SMPI_SAMPLE_LOCAL,
 141 SMPI_SAMPLE_GLOBAL and friends to indicate which computation loops can
 142 be sampled. Some of the loop iterations will be executed to measure
 143 their duration, and this duration will be used for the subsequent
 144 iterations. These samples are done per processor with
 145 SMPI_SAMPLE_LOCAL, and shared between all processors with
 146 SMPI_SAMPLE_GLOBAL. Of course, none of this will work if the execution
 147 time of your loop iteration are not stable.
 148
 149 Yes, that's right, these macros are not documented yet, but we'll fix
 150 it as soon as time permits. Sorry about that -- patch welcomed!
 151 Meanwhile, grep for them on the examples for more information.
 152
 153 \section SMPI_compiling Compiling your code
 154
 155 This is very simply done with the <tt>smpicc</tt> script. If you
 156 already compiled any MPI code before, you already know how to use it.
 157 If not, you should try to get your MPI code running on top of MPI
 158 before giving SMPI a spin. Actually, that's very simple even if it's
 159 the first time you use MPI code: just use smpicc as a compiler (in
 160 replacement of gcc or your usual compiler), and you're set.
 161
 162 \section SMPI_executing Executing your code on top of the simulator
 163
 164 This is done though the <tt>smpirun</tt> script as follows.
 165 <tt>my_hostfile.txt</tt> is a classical MPI hostfile (that is, this
 166 file lists the machines on which the processes must be dispatched, one
 167 per line)  <tt>my_platform.xml</tt> is a classical SimGrid platform
 168 file. Of course, the hosts of the hostfile must exist in the provided
 169 platform. <tt>./program</tt> is the MPI program that you want to
 170 simulate (must be compiled by <tt>smpicc</tt>) while <tt>-arg</tt> is
 171 a command-line parameter passed to this program.
 172
 173 \verbatim
 174 smpirun -hostfile my_hostfile.txt -platform my_platform.xml ./program -arg
 175 \endverbatim
 176
 177 smpirun accepts other parameters, such as <tt>-np</tt> if you don't
 178 want to use all the hosts defined in the hostfile, <tt>-map</tt> to
 179 display on which host each rank gets mapped of <tt>-trace</tt> to
 180 activate the tracing during the simulation. You can get the full list
 181 by running
 182 \verbatim
 183 smpirun -help
 184 \endverbatim
 185
 186
 187 */
 188
 189
 190 /** \defgroup SD_API      SimDag
 191     \ingroup SimGrid_API
 192     \brief Programming environment for DAG applications
 193
 194     SimDag provides some functionnalities to simulate parallel task scheduling
 195     with DAGs models (Direct Acyclic Graphs).
 196     The old versions of SimGrid were based on DAGs. But the DAG part (named SG)
 197     was removed in SimGrid 3 because the new kernel (\ref SURF_API) was implemented. \ref SURF_API
 198     was much faster and more flexible than SG and did not use DAGs.
 199     SimDag is a new implementation of DAGs handling and it is built on top of \ref SURF_API.
 200
 201     \section SD_who Who should use this (and who shouldn't)
 202
 203     You should use this programming environment of the SimGrid suite if you want
 204     to study algorithms and heuristics with DAGs of parallel tasks.
 205     If you don't need to use DAGs for your simulation, have a look at the
 206     \ref MSG_API programming environment.
 207     If you want to implement a real distributed application, have a look at the
 208     \ref GRAS_API programming environment.
 209     If you want to study an existing MPI program, have a look at the
 210     \ref SMPI_API one.
 211     If none of those programming environments fits your needs, you may
 212     consider implementing your own directly on top of \ref SURF_API (but you
 213     probably want to contact us before).
 214
 215 */
 216
 217 /**
 218 @defgroup SURF_API SURF
 219 @ingroup SimGrid_API
 220 @brief Internal kernel of all the simulators used in SimGrid, and associated models.
 221
 222 SURF provides the core functionnalities to simulate a virtual
 223 platform. It is very low-level and is not intended to be used by end
 224 users, but rather to serve as a basis for higher-level simulators. Its
 225 interface are not frozen (and will probably never be), and the
 226 structure emphasis on performance over ease of use. This module
 227 contains the platform models. If you need a model that is not encoded
 228 yet, please come to the devel mailing list so that we can discuss on
 229 the feasibility of your idea.
 230
 231 Please note that as it is not really intended for public use, this
 232 module is only partially documented.
 233 */
 234
 235
 236 /**
 237 @defgroup TRACE_API TRACE
 238 @ingroup SimGrid_API
 239 @brief Tracing mechanism and its functions.
 240
 241 SimGrid can trace the resource (of hosts and links) utilization using
 242 any of its programming interfaces (MSG, SimDAG and SMPI). This means
 243 that the tracing will register how much power is used for each host
 244 and how much bandwidth is used for each link of the platform.
 245
 246 The idea of the tracing facilities is to give SimGrid users to
 247 possibility to classify MSG and SimDAG tasks by category, tracing the
 248 platform utilization (hosts and links) for each of the categories.
 249 The API enables the declaration of categories and a function to
 250 associate them to the tasks (MSG and SD). The tasks that are not
 251 classified according to a category are not traced. If no categories
 252 are specified, simulations can still be traced using a special
 253 parameter in the command line (see \ref tracing_tracing for details).
 254 */
 255