include/gras/emul.h

   1 /* $Id$                     */
   2
   3 /* gras/emul.h - public interface to emulation support                      */
   4 /*                (specific parts for SG or RL)                             */
   5
   6 /* Copyright (c) 2003, 2004 Martin Quinson. All rights reserved.            */
   7
   8 /* This program is free software; you can redistribute it and/or modify it
   9  * under the terms of the license (GNU LGPL) which comes with this package. */
  10
  11 #ifndef GRAS_COND_H
  12 #define GRAS_COND_H
  13
  14 #include "xbt/misc.h" /* SG_BEGIN_DECL */
  15
  16 SG_BEGIN_DECL()
  17
  18 /** @addtogroup GRAS_emul
  19  *  @brief Code execution "emulation" and "virtualization".
  20  *
  21  * <center><table><tr><td><b>Top</b>    <td> [\ref index]::[\ref GRAS_API]
  22  *                <tr><td><b>Prev</b>   <td> [\ref GRAS_globals]
  23  *                <tr><td><b>Next</b>   <td> [\ref GRAS_main_generation]            </table></center>
  24  *
  25  *  Emulation and virtualization words have a lot of different meanings in
  26  *  computer science. Here is what we mean, and what this module allows you
  27  *  to do (if it does not match your personal belives, I'm sorry):
  28  *
  29  *  - Virtualization: Having some specific code for the simulation or for the reality
  30  *  - Emulation: Report within the simulator the execution time of your code
  31  *
  32  *  \section GRAS_emul_virtualization Virtualization
  33  *
  34  *  The whole idea of GRAS is to share the same code between the simulator
  35  *  and the real implementation. But it is sometimes impossible, such as
  36  *  when you want to deal with the OS. As an example, you may want to add
  37  *  some extra delay before initiating a communication in RL to ensure that
  38  *  the receiver is listening. This is usually useless in SG since you have
  39  *  a much better control on process launch time.
  40  *
  41  *  This would be done with the following snipet:
  42  *  \verbatim if (gras_if_RL())
  43    gras_os_sleep(1);\endverbatim
  44  *
  45  *  Please note that those are real functions and not pre-processor
  46  *  defines. This is to ensure that the same object code can be linked
  47  *  against the SG library or the RL one without recompilation.
  48  *
  49  *  @{
  50  */
  51
  52 /** \brief Returns true only if the program runs on real life */
  53 int gras_if_RL(void);
  54
  55 /** \brief Returns true only if the program runs within the simulator */
  56 int gras_if_SG(void);
  57
  58 /** @} */
  59
  60 int gras_bench_always_begin(const char *location, int line);
  61 int gras_bench_always_end(void);
  62 int gras_bench_once_begin(const char *location, int line);
  63 int gras_bench_once_end(void);
  64
  65 /** @addtogroup GRAS_emul
  66  *  \section GRAS_emul_timing Emulation
  67  *
  68  *  For simulation accuracy, it is mandatory to report the execution time
  69  *  of your code into the simulator. For example, if your application is a
  70  *  parallel matrix multiplication, you naturally have to slow down the
  71  *  simulated hosts actually doing the computation.
  72  *
  73  *  If you know beforehands how long each task will last, simply add a call
  74  *  to the gras_bench_fixed function described below. If not, you can have
  75  *  GRAS benchmarking your code automatically. Simply enclose the code to
  76  *  time between a macro GRAS_BENCH_*_BEGIN and GRAS_BENCH_*_END, and
  77  *  you're done. There is three pair of such macros, whose characteristics
  78  *  are summarized in the following table.
  79  *
  80  *  <table>
  81  *   <tr>
  82  *    <td><b>Name</b></td>
  83  *    <td><b>Run on host machine?</b></td>
  84  *    <td><b>Benchmarked?</b></td>
  85  *    <td><b>Corresponding time reported to simulation?</b></td>
  86  *   </tr>
  87  *   <tr>
  88  *    <td>GRAS_BENCH_ALWAYS_BEGIN()<br>
  89  *        GRAS_BENCH_ALWAYS_END()</td>
  90  *    <td>Each time</td>
  91  *    <td>Each time</td>
  92  *    <td>Each time</td>
  93  *   </tr>
  94  *   <tr>
  95  *    <td>GRAS_BENCH_ONCE_RUN_ONCE_BEGIN()<br>
  96  *        GRAS_BENCH_ONCE_RUN_ONCE_END()</td>
  97  *    <td>Only first time</td>
  98  *    <td>Only first time</td>
  99  *    <td>Each time (with stored value)</td>
 100  *   </tr>
 101  *   <tr>
 102  *    <td>GRAS_BENCH_ONCE_RUN_ALWAYS_BEGIN()<br>
 103  *        GRAS_BENCH_ONCE_RUN_ALWAYS_END()</td>
 104  *    <td>Each time</td>
 105  *    <td>Only first time</td>
 106  *    <td>Each time (with stored value)</td>
 107  *   </tr>
 108  *  </table>
 109  *
 110  *  As you can see, whatever macro pair you use, the corresponding value is
 111  *  repported to the simulator. After all, that's what those macro are
 112  *  about ;)
 113  *
 114  *  The GRAS_BENCH_ALWAYS_* macros are the simplest ones. Each time the
 115  *  corresponding block is encountered, the corresponding code is executed
 116  *  and timed. Then, the simulated host is given the corresponding amount
 117  *  of work.
 118  *
 119  *  The GRAS_BENCH_ONCE_RUN_ONCE_* macros are good for cases where you know
 120  *  that your execution time is constant and where you don't care about the
 121  *  result in simulation mode. In our example, each sub-block
 122  *  multiplication takes exactly the same amount of work (time depends only
 123  *  on size, not on content), and the operation result can safely be
 124  *  ignored for algorithm result. Doing so allows you to considerably
 125  *  reduce the amount of computation needed when running on simulator.
 126  *
 127  *  The GRAS_BENCH_ONCE_RUN_ALWAYS_* macros are good for cases where you
 128  *  know that each block will induce the same amount of work (you thus
 129  *  don't want to bench it each time), but you actually need the result (so
 130  *  you have to run it each time). You may ask why you don't use
 131  *  GRAS_BENCH_ONCE_RUN_ONCE_* macros in this case (why you save the
 132  *  benchmarking time).  The timing operation is not very intrusive by
 133  *  itself, but it has to be done in an exclusive way between the several
 134  *  GRAS threads (protected by mutex). So, the day where there will be
 135  *  threads in GRAS, this will do a big difference. Ok, I agree. For now,
 136  *  it makes no difference.
 137  *
 138  *  <b>Caveats</b>
 139  *
 140  *   - Blocks are automatically differenciated using the filename and line
 141  *     position at which the *_BEGIN part was called. Don't put two of them
 142  *     on the same line.
 143  *
 144  *   - You cannot nest blocks. It would make no sense, either.
 145  *
 146  *   - By the way, GRAS is not exactly designed for parallel algorithm such
 147  *     as parallel matrix multiplication but for distributed ones, you weirdo.
 148  *     But it's just an example ;)
 149  *
 150  * @{
 151  */
 152 /** \brief Start benchmarking this code block
 153     \hideinitializer */
 154 #define GRAS_BENCH_ALWAYS_BEGIN()           gras_bench_always_begin(__FILE__, __LINE__)
 155 /** \brief Stop benchmarking this code block
 156     \hideinitializer */
 157 #define GRAS_BENCH_ALWAYS_END()             gras_bench_always_end()
 158
 159 /** \brief Start benchmarking this code block if it has never been benchmarked, run it in any case
 160  *  \hideinitializer */
 161 #define GRAS_BENCH_ONCE_RUN_ALWAYS_BEGIN()  gras_bench_once_begin(__FILE__, __LINE__)
 162 /** \brief Stop benchmarking this part of the code
 163     \hideinitializer */
 164 #define GRAS_BENCH_ONCE_RUN_ALWAYS_END()    gras_bench_once_end()
 165
 166 /** \brief Start benchmarking this code block if it has never been benchmarked, ignore it if it was
 167     \hideinitializer */
 168 #define GRAS_BENCH_ONCE_RUN_ONCE_BEGIN()    if (gras_bench_once_begin(__FILE__, __LINE__)) {
 169 /** \brief Stop benchmarking this part of the code
 170     \hideinitializer */
 171 #define GRAS_BENCH_ONCE_RUN_ONCE_END()      } gras_bench_once_end()
 172 /** @} */
 173
 174 SG_END_DECL()
 175
 176 #endif /* GRAS_COND_H */
 177