SimGrid 3.6.2
Scalable simulation of distributed systems
|
Code execution "emulation" and "virtualization". More...
Defines | |
#define | GRAS_BENCH_ALWAYS_BEGIN() |
Start benchmarking this code block. | |
#define | GRAS_BENCH_ALWAYS_END() |
Stop benchmarking this code block. | |
#define | GRAS_BENCH_ONCE_RUN_ALWAYS_BEGIN() |
Start benchmarking this code block if it has never been benchmarked, run it in any case. | |
#define | GRAS_BENCH_ONCE_RUN_ALWAYS_END() |
Stop benchmarking this part of the code. | |
#define | GRAS_BENCH_ONCE_RUN_ONCE_BEGIN() |
Start benchmarking this code block if it has never been benchmarked, ignore it if it was. | |
#define | GRAS_BENCH_ONCE_RUN_ONCE_END() |
Stop benchmarking this part of the code. | |
Functions | |
int | gras_if_RL (void) |
Returns true only if the program runs on real life. | |
int | gras_if_SG (void) |
Returns true only if the program runs within the simulator. |
Code execution "emulation" and "virtualization".
Emulation and virtualization words have a lot of different meanings in computer science. Here is what we mean, and what this module allows you to do (if it does not match your personal belives, I'm sorry):
The whole idea of GRAS is to share the same code between the simulator and the real implementation. But it is sometimes impossible, such as when you want to deal with the OS. As an example, you may want to add some extra delay before initiating a communication in RL to ensure that the receiver is listening. This is usually useless in SG since you have a much better control on process launch time.
This would be done with the following snipet:
if (gras_if_RL()) gras_os_sleep(1);
Please note that those are real functions and not pre-processor defines. This is to ensure that the same object code can be linked against the SG library or the RL one without recompilation.
For simulation accuracy, it is mandatory to report the execution time of your code into the simulator. For example, if your application is a parallel matrix multiplication, you naturally have to slow down the simulated hosts actually doing the computation.
If you know beforehands how long each task will last, simply add a call to the gras_bench_fixed function described below. If not, you can have GRAS benchmarking your code automatically. Simply enclose the code to time between a macro GRAS_BENCH_*_BEGIN and GRAS_BENCH_*_END, and you're done. There is three pair of such macros, whose characteristics are summarized in the following table.
Name | Run on host machine? | Benchmarked? | Corresponding time reported to simulation? |
GRAS_BENCH_ALWAYS_BEGIN() GRAS_BENCH_ALWAYS_END() | Each time | Each time | Each time |
GRAS_BENCH_ONCE_RUN_ONCE_BEGIN() GRAS_BENCH_ONCE_RUN_ONCE_END() | Only first time | Only first time | Each time (with stored value) |
GRAS_BENCH_ONCE_RUN_ALWAYS_BEGIN() GRAS_BENCH_ONCE_RUN_ALWAYS_END() | Each time | Only first time | Each time (with stored value) |
As you can see, whatever macro pair you use, the corresponding value is repported to the simulator. After all, that's what those macro are about ;)
The GRAS_BENCH_ALWAYS_* macros are the simplest ones. Each time the corresponding block is encountered, the corresponding code is executed and timed. Then, the simulated host is given the corresponding amount of work.
The GRAS_BENCH_ONCE_RUN_ONCE_* macros are good for cases where you know that your execution time is constant and where you don't care about the result in simulation mode. In our example, each sub-block multiplication takes exactly the same amount of work (time depends only on size, not on content), and the operation result can safely be ignored for algorithm result. Doing so allows you to considerably reduce the amount of computation needed when running on simulator.
The GRAS_BENCH_ONCE_RUN_ALWAYS_* macros are good for cases where you know that each block will induce the same amount of work (you thus don't want to bench it each time), but you actually need the result (so you have to run it each time). You may ask why you don't use GRAS_BENCH_ONCE_RUN_ONCE_* macros in this case (why you save the benchmarking time). The timing operation is not very intrusive by itself, but it has to be done in an exclusive way between the several GRAS threads (protected by mutex). So, the day where there will be threads in GRAS, this will do a big difference. Ok, I agree. For now, it makes no difference.
Caveats
Back to the main Simgrid Documentation page |
The version of Simgrid documented here is v3.6.2. Documentation of other versions can be found in their respective archive files (directory doc/html). |
Generated for SimGridAPI by
![]() |