- - <b>Enable GTNetS support in SimGrid</b>
-
-In order to enable gtnets with simgrid you have to give where is gtnets. (path to <gtnets_path>/lib and <gtnets_path>/include)
-
- \verbatim
- Since v3.4 (with cmake)
- cmake . -Dgtnets_path=/<userhome>/usr
-
- Until v3.4 (with autotools)
- ./configure --with-gtnets=/<userhome>/usr
- \endverbatim
-
- - <b>Once you have followed all the instructions for compiling and
- installing successfully you can activate this feature at
- runntime with the following options:</b>
-
- \verbatim
- Since v3.4 (with cmake)
- cd simgrid
- make
- ctest -R gtnets
-
- Until v3.4 (with autotools)
- cd simgrid/example/msg/
- make
- make check
- \endverbatim
-
-
- - <b>Or try the GTNetS model dogbone example with</b>
-
- \verbatim
- gtnets/gtnets gtnets/onelink-p.xml gtnets/onelink-d.xml --cfg=network_model:GTNets
- \endverbatim
-
-
- A long version of this <a href="http://gforge.inria.fr/docman/view.php/12/6283/GTNetS HowTo.html">HowTo</a> it is available
-
-
- More about GTNetS simulator at <a href="http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/index.html">GTNetS Website</a>
-
-
- - <b>DISCLAIMER</b>
- The patches provided by us worked successfully with GTNetS found
- <a href="http://www.ece.gatech.edu/research/labs/MANIACS/GTNetS/software/gtnets-current.zip">here</a>,
- dated from 12th June 2008. Due to the discontinuing development of
- GTNetS it is impossible to precise a version number. We STRONGLY recommend you
- to download and install the GTNetS version found in SimGrid repository as explained above.
-
-
-
-
-\subsubsection faq_simgrid_configuration_alternate_network Using alternative flow models
-
-The default simgrid network model uses a max-min based approach as
-explained in the research report
-<a href="ftp://ftp.ens-lyon.fr/pub/LIP/Rapports/RR/RR2002/RR2002-40.ps.gz">A Network Model for Simulation of Grid Application</a>.
-Other models have been proposed and implemented since then (see for example
-<a href="http://mescal.imag.fr/membres/arnaud.legrand/articles/simutools09.pdf">Accuracy Study and Improvement of Network Simulation in the SimGrid Framework</a>)
-and can be activated at runtime. For example:
-\verbatim
-./mycode platform.xml deployment.xml --cfg=workstation/model:compound --cfg=network/model:LV08 -cfg=cpu/model:Cas01
-\endverbatim
-
-Possible models for the network are currently "Constant", "CM02",
-"LegrandVelho", "GTNets", Reno", "Reno2", "Vegas". Others will
-probably be added in the future and many of the previous ones are
-experimental and are likely to disappear without notice... To know the
-list of the currently implemented models, you should use the
---help-models command line option.
-
-\verbatim
-./masterslave_forwarder ../small_platform.xml deployment_masterslave.xml --help-models
-Long description of the workstation models accepted by this simulator:
- CLM03: Default workstation model, using LV08 and CM02 as network and CPU
- compound: Workstation model allowing you to use other network and CPU models
- ptask_L07: Workstation model with better parallel task modeling
-Long description of the CPU models accepted by this simulator:
- Cas01_fullupdate: CPU classical model time=size/power
- Cas01: Variation of Cas01_fullupdate with partial invalidation optimization of lmm system. Should produce the same values, only faster
- CpuTI: Variation of Cas01 with also trace integration. Should produce the same values, only faster if you use availability traces
-Long description of the network models accepted by this simulator:
- Constant: Simplistic network model where all communication take a constant time (one second)
- CM02: Realistic network model with lmm_solve and no correction factors
- LV08: Realistic network model with lmm_solve and these correction factors: latency*=10.4, bandwidth*=.92, S=8775
- Reno: Model using lagrange_solve instead of lmm_solve (experts only)
- Reno2: Model using lagrange_solve instead of lmm_solve (experts only)
- Vegas: Model using lagrange_solve instead of lmm_solve (experts only)
-\endverbatim
-
-\subsection faq_tracing Tracing Simulations for Visualization
-
-The trace visualization is widely used to observe and understand the behavior
-of parallel applications and distributed algorithms. Usually, this is done in a
-two-step fashion: the user instruments the application and the traces are
-analyzed after the end of the execution. The visualization itself can highlights
-unexpected behaviors, bottlenecks and sometimes can be used to correct
-distributed algorithms. The SimGrid team is currently instrumenting the library
-in order to let users trace their simulations and analyze them. This part of the
-user manual explains how the tracing-related features can be enabled and used
-during the development of simulators using the SimGrid library.
-
-\subsubsection faq_tracing_howitworks How it works
-
-For now, the SimGrid library is instrumented so users can trace the <b>platform
-utilization</b> using the MSG interface. This means that the tracing will
-register how much power is used for each host and how much bandwidth is used for
-each link of the platform. The idea with this type of tracing is to observe the
-overall view of resources utilization in the first place, especially the
-identification of bottlenecks, load-balancing among hosts, and so on.
-
-The idea of the instrumentation is to classify the MSG tasks by category,
-and trace
-the platform utilization (hosts and links) for each of the categories. For that,
-the tracing interface enables the declaration of categories and a function to
-mark a task with a previously declared category. <em>The tasks that are not
-classified according to a category are not traced</em>.
-
-\subsubsection faq_tracing_enabling Enabling using CMake
-
-With the sources of SimGrid, it is possible to enable the tracing
-using the parameter <b>-Denable_tracing=ON</b> when the cmake is executed.
-The section \ref faq_tracing_functions describes all the functions available
-when this Cmake options is activated. These functions will have no effect
-if SimGrid is configured without this option (they are wiped-out by the
-C-preprocessor).
-
-\verbatim
-$ cmake -Denable_tracing=ON .
-$ make
-\endverbatim
-
-\subsubsection faq_tracing_functions Tracing Functions
-
-\subsubsubsection Mandatory Functions
-
-\li <b>\c TRACE_start ()</b>: This is the first function to
-be called. It returns 0 if everything was properly initialized, 1 otherwise.
-All trace functions called before TRACE_start do nothing.
-
-\li <b>\c TRACE_category (const char *category)</b>: This function should be used
-to define a user category. The category can be used to differentiate the tasks
-that are created during the simulation (for example, tasks from server1,
-server2, or request tasks, computation tasks, communication tasks).
-All resource utilization (host power and link bandwidth) will be
-classified according to the task category. Tasks that do not belong to a
-category are not traced.
-
-\li <b>\c TRACE_msg_set_task_category (m_task_t task, const char *category)</b>:
-This function should be called after the creation of a task, to define the
-category of that task. The first parameter \c task must contain a task that was
-created with the function \c MSG_task_create. The second parameter
-\c category must contain a category that was previously defined by the function
-\c TRACE_category.
-
-\li <b>\c TRACE_end ()</b>: This is the last function to be called. It closes
-the trace file and stops the tracing of the simulation. All tracing will be
-completely disabled after the calling this function. Although we recommend
-the use of this function somewhere in the end of program, it can be used
-anywhere in the code. This function returns 0 if everything is ok, 1 otherwise.
-
-\subsubsubsection Optional Functions
-
-\li <b>\c TRACE_host_variable_declare (const char *variable)</b>:
-Declare a user variable that will be associated to hosts. A variable can
-be used to trace user variables such as the number of tasks in a server,
-the number of clients in an application, and so on.
-
-\li <b>\c TRACE_host_variable_[set|add|sub] (const char *variable, double
-value)</b>:
-Set the value of a given user variable. It is important to remind that
-the value of this variable is always associated to the host. The host
-that will be used when these functions are called is the one returned by
-the function \c MSG_host_self().
-
-\subsubsection faq_tracing_options Tracing configuration Options
-
-These are the options accepted by the tracing system of SimGrid:
-
-\li <b>\c tracing/filename</b>: use this to specify the name of the trace file
-that will be created during the simulation. For example, after the binary
-of your simulator, you can pass as parameter this:
-\verbatim
---cfg=tracing/filename:mytracefile.trace
-\endverbatim
-in order to trace the behavior of the simulation in a file with the name
-mytracefile.trace.
-
-\li <b>\c tracing/platform</b>: use this to activate the tracing of the
-platform. For example, you can pass as parameter to your simulator:
-\verbatim
---cfg=tracing/platform:1
-\endverbatim
-to trace the platform utilization by the categories you declared in your
-simulator. By default, this options is set to 0.
-
-\subsubsection faq_tracing_example Example of Instrumentation
-
-A simplified example using the tracing mandatory functions.
-
-\verbatim
-int main (int argc, char **argv)
-{
- MSG_global_init (&argc, &argv);
-
- //note that TRACE_start must be called after MSG_global_init
- TRACE_start ();
- TRACE_category ("request");
- TRACE_category ("computation");
- TRACE_category ("finalize");
-
- //(... after deployment ...)
-
- m_task_t req1 = MSG_task_create("1st_request_task", 10, 10, NULL);
- m_task_t req2 = MSG_task_create("2nd_request_task", 10, 10, NULL);
- m_task_t req3 = MSG_task_create("3rd_request_task", 10, 10, NULL);
- m_task_t req4 = MSG_task_create("4th_request_task", 10, 10, NULL);
- TRACE_msg_set_task_category (req1, "request");
- TRACE_msg_set_task_category (req2, "request");
- TRACE_msg_set_task_category (req3, "request");
- TRACE_msg_set_task_category (req4, "request");
-
- m_task_t comp = MSG_task_create ("comp_task", 100, 100, NULL);
- TRACE_msg_set_task_category (comp, "computation");
-
- m_task_t finalize = MSG_task_create ("finalize", 0, 0, NULL);
- TRACE_msg_set_task_category (finalize, "finalize");
-
- //(...)
-
- MSG_clean();
-
- TRACE_end();
- return 0;
-}
-\endverbatim
-
-\subsubsection faq_tracing_analyzing Analyzing the SimGrid Traces
-
-The SimGrid library, during an instrumented simulation, creates a trace file in
-the Paje file format that contains the platform utilization for the simulation
-that was executed. The visualization analysis of this file is performed with the
-visualization tool <a href="http://triva.gforge.inria.fr">Triva</a>, with
-special configurations tunned to SimGrid needs. This part of the documentation
-explains how to configure and use Triva to analyse a SimGrid trace file.
-
-- <b>Installing Triva</b>: the tool is available in the INRIAGforge,
-at <a href="http://triva.gforge.inria.fr">http://triva.gforge.inria.fr</a>.
-Use the following command to get the sources, and then check the file
-<i>INSTALL.simplified</i>. This file contains instructions to install
-the tool's dependencies in a Ubuntu/Debian Linux.
-\verbatim
-$ svn checkout svn://scm.gforge.inria.fr/svn/triva
-$ cd triva
-$ cat INSTALL.simplified
-\endverbatim
-
-- <b>Executing Triva</b>: a binary called <i>Triva</i> is available after the
- installation (you can execute it passing <em>--help</em> to check its
-options). If the triva binary is not available after following the
-installation instructions, you may want to execute the following command to
-initialize the GNUstep environment variables (note that the location of the
-<i>GNUstep.sh</i> file may vary depending on your GNUstep installation - the
-command is known to work in Ubuntu and Debian Linux):
-\verbatim
-$ source /usr/share/GNUstep/Makefiles/GNUstep.sh
-\endverbatim
-You should be able to see this output after the installation of triva:
-\verbatim
-$ ./Triva.app/Triva --help
-Usage: Triva [OPTION...] TRACEFILE
-Trace Analysis through Visualization
-
- You need to use one of the following options:
- -g, --graph Graph Analysis
- -t, --treemap Treemap Analysis
-
- Other auxiliary options to check the trace file:
- -c, --check Check the integrity of trace file
- -h, --hierarchy Export the trace type hierarchy
- -l, --list List entity types
-
- -?, --help Give this help list
- --usage Give a short usage message
-\endverbatim
-Triva expects that the user choose one of the available options
-(currently <em>--graph</em> or <em>--treemap</em> for a visualization analysis)
-and the trace file from the simulation.
-
-- <b>Understanding Triva - time-slice</b>: the analysis of a trace file using
- the tool always takes into account the concept of the <em>time-slice</em>.
-This concept means that what is being visualized in the screen is always
-calculated considering a specific time frame, with its beggining and end
-timestamp. The time-slice is configured by the user and can be changed
-dynamically through the window called <em>Time Interval</em> that is opened
-whenever a trace file is being analyzed. The next figure depicts the time-slice
-configuration window.
-In the top of the window, in the space named <i>Trace Time</i>,
-the two fields show the beggining of the trace (which usually starts in 0) and
-the end (that depends on the time simulated by SimGrid). The middle of the
-window, in the square named <i>Time Slice Configuration</i>, contains the
-aspects related to the time-slice, including its <i>start</i> and its
-<i>size</i>. The gray rectangle in the bottom of this part indicates the
-<i>current time-slice</i> that is considered for the drawings. If the checkbox
-<i>Update Drawings on Sliders Change</i> is not selected, the button
-<i>Apply</i> must be clicked in order to inform triva that the
-new time-slice must be considered. The bottom part of the window, in the space
-indicated by the square <i>Time Slice Animation</i> can be used to advance
-the time-frame automatically. The user configures the amount of time that the
-time-frame will forward and how frequent this update will happen. Once this is
-configured, the user clicks the <i>Play</i> button in order to see the dynamic
-changes on the drawings.
-<center>
-\htmlonly
-<a href="triva-time_interval.png" border=0><img src="triva-time_interval.png" width="50%" border=0></a>
-\endhtmlonly
-</center>
-<b>Remarks:</b> when the trace has too many hosts or links, the computation to
-take into account a new time-slice can be expensive. When this happens, the
-<i>Frequency</i> parameter, but also updates caused by change on configurations
-when the checkbox <i>Update Drawings on Sliders
-Change</i> is selected will not be followed.
-
-- <b>Understanding Triva - graph</b>: this part of the documention explains how
- to analyze the traces using the graph view of Triva, when the user executes
-the tool passing <em>--graph</em> as parameter. Triva opens three windows when
-this parameter is used: the <i>Time Interval</i> window (previously described),
-the <i>Graph Representation</i> window, and the <em>Graph Configuration</em>
-window. The Graph Representation is the window where drawings take place.
-Initially, it is completely white waiting for a proper graph configuration input
-by the user. We start the description of this type of analysis by describing the
-<i>Graph Configuration</i> window (depicted below). By using a particular
-configuration, triva
-can be used to customize the graph drawing according to
-the SimGrid trace that was created with user-specific categories. Before delving
-into the details of this customization, let us first explain the major parts of
-the graph configuration window. The buttons located in the top-right corner can
-be used to delete, copy and create a new configuration. The checkbox in the
-top-middle part of the window indicates if the configuration typed in the
-textfield is syntactically correct (we are using the non-XML
-<a href="http://en.wikipedia.org/wiki/Property_list">Property List Format</a> to
-describe the configuration). The pop-up button located on the top-left corner
-indicates the selected configuration (the user can have multiple graph
-configurations). The bottom-left text field contains the name of the current
-configuration (updates on this field must be followed by typing enter on the
-keyboard to take into account the name change). The bottom-right <em>Apply</em>
-button activates the current configuration, resulting on an update on the graph
-drawings.
-<center>
-\htmlonly
-<a href="triva-graph_configuration.png" border=0><img src="triva-graph_configuration.png" width="50%" border=0></a>
-\endhtmlonly
-</center>
-<b>Basic SimGrid Configuration</b>: The figure shows in the big textfield the
-basic configuration that should be used during the analysis of a SimGrid trace
-file. The basic logic of the configuration is as follows:
-\verbatim
-{
- node = (HOST);
- edge = (LINK);
-\endverbatim
-The nodes of the graph will be created based on the <i>node</i> parameter, which
-in this case is the different <em>"HOST"</em>s of the platform
-used to simulate. The <i>edge</i> parameter indicates that the edges of the
-graph will be created based on the <em>"LINK"</em>s of the platform. After the
-definition of these two parameters, the configuration must detail how
-<em>HOST</em>s and <em>LINK</em>s should be drawn. For that, the configuration
-must have an entry for each of the types used. For <em>HOST</em>, as basic
-configuration, we have:
-\verbatim
- HOST = {
- size = power;
- scale = global;
- };
-\endverbatim
-The parameter <em>size</em> indicates which variable from the trace file will be
-used to define the size of the node HOST in the visualization. If the simulation
-was executed with availability traces, the size of the nodes will be changed
-according to these traces. The parameter <em>scale</em> indicates if the value
-of the variable is <em>global</em> or <em>local</em>. If it is global, the value
-will be relative to the power of all other hosts, if it is local, the value will
-be relative locally.
-For <em>LINK</em> we have:
-\verbatim
- LINK = {
- src = source;
- dst = destination;
-
- size = bandwidth;
- scale = global;
- };
-\endverbatim
-For the types specified in the <em>edge</em> parameter (such as <em>LINK</em>),
-the configuration must contain two additional parameters: <em>src</em> and
-<em>dst</em> that are used to properly identify which nodes this edge is
-connecting. The values <em>source</em> and <em>destination</em> are always present
-in the SimGrid trace file and should not be changed in the configuration. The
-parameter <em>size</em> for the LINK, in this case, is configured as the
-variable <em>bandwidth</em>, with a <em>global</em> scale. The scale meaning
-here is exactly the same used for nodes. The last parameter is the GraphViz
-algorithm used to calculate the position of the nodes in the graph
-representation.
-\verbatim
- graphviz-algorithm = neato;
-}
-\endverbatim
-<b>Customizing the Graph Representation</b>: triva is capable to handle
-a customized graph representation based on the variables present in the trace
-file. In the case of SimGrid, every time a category is created for tasks, two
-variables in the trace file are defined: one to indicate node utilization (how
-much power was used by that task category), and another to indicate link
-utilization (how much bandwidth was used by that category). For instance, if the
-user declares a category named <i>request</i>, there will be variables named
-<b>p</b><i>request</i> and a <b>b</b><i>request</i> (<b>p</b> for power and
-<b>b</b> for bandwidth). It is important to notice that the variable
-<i>prequest</i> in this case is only available for HOST, and
-<i>brequest</i> is only available for LINK. <b>Example</b>: suppose there are
-two categories for tasks: request and compute. To create a customized graph
-representation with a proportional separation of host and link utilization, use
-as configuration for HOST and LINK this:
-\verbatim
- HOST = {
- size = power;
- scale = global;
-
- sep_host = {
- type = separation;
- size = power;
- values = (prequest, pcomputation);
- };
- };
-
- LINK = {
- src = source;
- dst = destination;
- size = bandwidth;
- scale = global;
-
- sep_link = {
- type = separation;
- size = bandwidth;
- values = (brequest, bcomputation);
- };
- };
-\endverbatim
-Where <i>sep_host</i> contains a composition of type <i>separation</i> where
-its max size is the <i>power</i> of the host and the variables <i>prequest</i>
-and <i>pcomputation</i> are drawn proportionally to the size of the HOST. And
-<i>sep_link</i> is also a separation where max is defined as the
-<i>bandwidth</i> of the link, and the variables <i>brequest</i> and
-<i>bcomputation</i> are drawn proportionally within a LINK.
-<i>This configuration enables the analysis of resource utilization by MSG tasks,
-and the identification of load-balancing issues, network bottlenecks, for
-instance.</i> \n
-<b>Other compositions</b>: besides <i>separation</i>, it is possible to use
-other types of compositions, such as gradients, and colors, like this:
-\verbatim
- gra_host = {
- type = gradient;
- scale = global;
- values = (numberOfTasks);
- };
- color_host = {
- type = color;
- values = (is_server);
- };
-\endverbatim
-Where <i>gra_host</i> creates a gradient within a node of the graph, using a
-global scale and using as value a variable called <i>numberOfTasks</i>, that
-could be declared by the user using the optional tracing functions of SimGrid.
-If scale is global, the max and min value for the gradient will be equal to the
-max and min numberOfTasks among all hosts, and if scale is local, the max and
-min value based on the value of numberOfTasks locally in each host.
-And <i>color_host</i> composition draws a square based on a positive value of
-the variable <i>is_server</i>, that could also be defined by the user using the
-SimGrid tracing functions. \n
-<b>The Graph Visualization</b>: The next figure shows a graph visualization of a
-given time-slice of the masterslave_forwarder example (present in the SimGrid
-sources). The red color indicates tasks from the <i>compute</i> category. This
-visualization was generated with the following configuration:
-\verbatim
-{
- node = (HOST);
- edge = (LINK);
-
- HOST = {
- size = power;
- scale = global;
-
- sep_host = {
- type = separation;
- size = power;
- values = (pcompute, pfinalize);
- };
- };
- LINK = {
- src = source;
- dst = destination;
- size = bandwidth;
- scale = global;
-
- sep_link = {
- type = separation;
- size = bandwidth;
- values = (bcompute, bfinalize);
- };
- };
- graphviz-algorithm = neato;
-}
-\endverbatim
-<center>
-\htmlonly
-<a href="triva-graph_visualization.png" border=0><img src="triva-graph_visualization.png" width="50%" border=0></a>
-\endhtmlonly
-</center>
-
-- <b>Understading Triva - colors</b>: An important issue when using Triva is how
- to define colors. To do that, we have to know which variables are defined in
-the trace file generated by the SimGrid library. The parameter <em>--list</em>
-lists the variables for a given trace file:
-\verbatim
-$ Triva -l masterslave_forwarder.trace
-iFile
-c platform
-c HOST
-v power
-v is_slave
-v is_master
-v task_creation
-v task_computation
-v pcompute
-v pfinalize
-c LINK
-v bandwidth
-v latency
-v bcompute
-v bfinalize
-c user_type
-\endverbatim
-We can see that HOST has seven variables (from power to pfinalize) and LINK has
-four (from bandwidth to bfinalize). To define a red color for the
-<i>pcompute</i> and <i>bcompute</i> (which are defined based on user category
-<i>compute</i>), execute:
-\verbatim
-$ defaults write Triva 'pcompute Color' '1 0 0'
-$ defaults write Triva 'bcompute Color' '1 0 0'
-\endverbatim
-Where the three numbers in each line are the RGB color with values from 0 to 1.
-
-\subsection faq_modelchecking Model-Checking
-\subsubsection faq_modelchecking_howto How to use it
-To enable the experimental SimGrid model-checking support the program should
-be executed with the command line argument
-\verbatim
---cfg=model-check:1
-\endverbatim
-Properties are expressed as assertions using the function
-\verbatim
-void MC_assert(int prop);
-\endverbatim
-
-\subsection faq_binding_lua Lua Binding
-Most of Simgrid modules require a good level in C programming, since simgrid is used to be as standard C library.
- Sometime users prefer using some kind of « easy scripts » or a language easier to code with, for their works,
- which avoid dealing with C errors, and sometime an important gain of time.
-Besides Java Binding, Lua and Ruby bindings are available since version 3.4 of Simgrid
-for MSG Module, and we are currenlty working on bindings for other modules.
-
-
-\subsubsection faq_binding_lua_about What is lua ?
-Lua is a lightweight, reflective, imperative and functional programming language,
- designed as a scripting language with extensible semantics as a primary goal (see official web site <a href="http://www.lua.org">here</a>).
-\subsubsection faq_binding_lua_why Why lua ?
-Lua is a fast, portable and powerful script language, quite simple to use for developpers.
-it combines procedural features with powerful data description facilities,
- by using a simple, yet powerful, mechanism of tables.
-Lua has a relatively simple C API compared to other scripting languages,
-and accordingly it provides a robust, easy to use it.
-\subsubsection faq_binding_lua_simgrid How to use lua in Simgrid ?
-Actually, the use of lua in Simgrid is quite simple, you have just to follow the same steps as coding with C in Simgird :
- - Coding functions coresponding to each process
- - loading the platforme/deployment XML file that describe the environment of simulation
- - and … Running the Simulation.
-
-\dontinclude lua/master_slave.lua
-\subsubsection faq_binding_lua_example_master_slave Master/Slave Example
-
- \li Master Code
- \until end_of_master
-we mainly use simgrid.Task.new(task_name,computation_size,communication_size) to create our MSG Task,
- then simgrid.Task.send(task,alias) to send it.
-we use also simgrid.Task.name(task), to get the task's name.
-
-\li Slave Code
-\until end_of_slave
-Here, we see the use of simgrid.Task.recv(alias) to receive a task with a specific alias,
-this function return directly the task recevied.
-
-\li Set Environmenet and run application
-\until simgrid.clean()
-
-\subsubsection faq_binding_lua_example_data Exchanging Data
-You can also exchange data between Process using lua. for that, you have to deal with lua task as a table,
-since lua is based itself on a mechanism of tables,
-so you can exchange any kind of data (tables, matrix, strings,…) between process via tasks.
-
-\li Sender process
-\verbatim
- task = simgrid.Task.new("data_task",task_comp,task_comm);
- task['matrix'] = my_matrix;
- task['table'] = my_table;
- task['message'] = "Hello from (Lua || Simgrid ) !! "
- …
- simgrid.Task.send(task,alias)
-\endverbatim
- After creating task, we associate to it various kind of data with a specific key (string in this case)
- to distinguish between data variables. The receiver will use this key to access easily to datas.
-
-
-\li Receiver processe
-\verbatim
- task = simgrid.Task.recv(alias);
- sender_matrix = task['matrix'];
- sender_table = task['table'];
- sender_message = task['message']
- ...
-\endverbatim
- Note that in lua, both sender and receiver share the same lua task.
- So that the receiver could joint data directly on the received task without sending it back.
- You can find a complet example (matrix multiplication case) in the file example/lua/mult_matrix.lua.
-
-
-\subsubsection faq_binding_lua_example_bypass Bypass XML
- maybe you wonder if there is a way to bypass the XML files,
- and describe your platform directly from the code, with lua bindings it's Possible !! how ?
- We provide some additional (tricky?) functions in lua that allows you to set up your own platform without using the XML files
- ( this can be useful for large platforms, so a simple for loop will avoid you to deal with an annoying XML File ;) )
-
-
-\li set Routing mode
-\verbatim
- simgrid.AS.new{id="AS0",mode="Full"};
-\endverbatim
-
-\li set Hosts
-\verbatim
- simgrid.Host.new{id="Tremblay",power=98095000};
- simgrid.Host.new{id="Jupiter",power=76296000};
- simgrid.Host.new{id="Fafard",power=76296000};
- simgrid.Host.new{id="Ginette",power=48492000};
- simgrid.Host.new{id="Bourassa",power=48492000};
-\endverbatim
- we use simgrid.Host.new{id=id_host,power=power_host} to instanciate our hosts.
-
-\li set Links
-\verbatim
- for i=0,11 do
- simgrid.Link.new{id=i,bandwidth=252750+ i*768,latency=0.000270544+i*0.087}; -- some crazy values ;)
- end
-\endverbatim
- we used simgrid.Link.new{id=link_id,bandwidth=bw,latency=lat} with a simple for loop to create all links we need (much easier than XML hein ?)
-
-\li set Routes
-\verbatim
--- simgrid.Route.new(src_id,des_id,links_nb,links_list)
- simgrid.Route.new("Tremblay","Jupiter",1,{"1"});
- simgrid.Route.new("Tremblay","Fafard",6,{"0","1","2","3","4","8"});
- simgrid.Route.new("Tremblay","Ginette",3,{"3","4","5"});
- simgrid.Route.new("Tremblay","Bourassa",7,{"0","1","3","2","4","6","7"});
-
- simgrid.Route.new("Jupiter","Tremblay",1,{"1"});
- simgrid.Route.new("Jupiter","Fafard",7,{"0","1","2","3","4","8","9"});
- simgrid.Route.new("Jupiter","Ginette",4,{"3","4","5","9"});
- simgrid.Route.new("Jupiter","Bourassa",8,{"0","1","2","3","4","6","7","9"});
- ...
-\endverbatim
- for each host you have to specify which route to choose to access to the rest of hosts connected in the grid.
-
-\li Save platform
-\verbatim
- simgrid.register_platform();
-\endverbatim
-Don't forget to register your platform, that SURF callbacks starts their work ;)
-
-\li set application
-\verbatim
- simgrid.Host.setFunction("Tremblay","Master",4,{"20","550000000","1000000","4"});
- simgrid.Host.setFunction("Bourassa","Slave",1,{"0"});
- simgrid.Host.setFunction("Jupiter","Slave",1,{"1"});
- simgrid.Host.setFunction("Fafard","Slave",1,{"2"});
- simgrid.Host.setFunction("Ginette","Slave",1,{"3"});
-\endverbatim
- you don't need to use a deployment XML file, thanks to simgrid.Host.setFunction(host_id,function,args_number,args_list)
- you can associate functions for each host with arguments if needed .
-
-\li
-\verbatim
- simgrid.register_application();
-\endverbatim
-Yes, Here too you have to resgiter your application before running the simulation.
-
-the full example is distributed in the file examples/lua/master_slave_bypass.lua
-
-\subsection faq_binding_ruby Ruby Binding
-
-
-\subsubsection faq_binding_ruby_simgrid Use Ruby in Simgrid
-Since v3.4, the use of <a href="http://ruby-lang.org">ruby</a> in simgrid is available for the MSG Module.
-you can find almost all MSG functionalities in Ruby code, that allows you to set up your environment, manage tasks between hosts and run the simulation.
-
-\dontinclude ruby/MasterSlave.rb
-\subsubsection faq_binding_ruby_example Master/Slave Ruby Application
-for each process method(master and slave in this example), you have to associate a ruby class, that should inherit from <i>MSG::Process</i> ruby class,
- with a 'main' function that describe the behaviour of the process during the simulation.
-\li required stuff
-\verbatim
-require 'simgrid'
-include MSG
-\endverbatim
-
-\li Master code
-\until end_of_master
-
-the class MSG::Task contains methods that allows the management of the native MSG tasks.
-in master ruby code we used :
- - <i>MSG::Task.new(task_name,compute_size,communication_size)</i> : to instanciate a new task.
- - <i>MSG::Task.send(mailbox)</i> : to send the task via a mailbox alias.
- - <i>MSG::Task.name</i> : to get the task's name.
-
-\li Slave code
-\until end_of_slave
-to receive a task, we use the method <i>MSG::Task.receive(mailbox)</i> that return a MSG:Task object (received task).
-
-\li Main chunk
-\until MSG.exit
-
-- <i>MSG.createEnvironment(platform_file)</i> : set up the environment
-- <i>MSG.deployApplication(deployment_file)</i> : load the deployment file description.
-- <i>MSG.run</i> : run the simulation
-
-\subsubsection faq_binding_ruby_data Exchanging data
-ruby bindings provides two ways to exchange data between ruby processes.
-\li MSG::Task.join & MSG::Task.data \br
-
- the MSG::Task class contains 2 methods that allows a data exchange between 2 process.
-
- -<i>MSG::Task.join</i> : makes possible to join any kind of ruby data within a task.
- \verbatim
- ...
- myTable = Array.new
- myTable <<1<<-2<<45<<67<<87<<76<<89<<56<<78<<3<<-4<<99
- # Creates and send Task With the Table inside
- task = MSG::Task.new("quicksort_task",taskComputeSize, taskCommunicationSize);
- task.join(myTable);
- ...
- task.send(mailbox);
- \endverbatim
- -<i>MSG::Task.data</i> : to access to the data contained into the task.
- \verbatim
- ...
- task = MSG::Task.receive(recv_mailbox.to_s)
- table = task.data
- quicksort(table,0,table.size-1)
- ...
- \endverbatim
-you can find a complet example illustrating the use of those methods in file /example/ruby/Quicksort.rb
-
-\li inheritence
-
- another 'object-oriented' way to do it, is to make your own 'task' class that inherit from MSG::Task ,
- and contains data you want to deal with, the only 'tricky' thing is that "the initializer" method has no effect !
-
- the use of some getter/setter methods would be the simple way to manage your data :)
- \verbatim
-class PingPongTask < MSG::Task
- # The initialize method has no effect
- @time
- def setTime(t)
- @time = t
- end
- def getTime()
- return @time
- end
-end
- \endverbatim
- you can find an example of use in file example/ruby/PingPong.rb