X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/5629ee08839a59133fbc0b00f4f6f1b4b098334e..51fa7ffbdb2ae1429a64334ec7636ddeb13824c7:/doc/FAQ.doc

diff --git a/doc/FAQ.doc b/doc/FAQ.doc
index 0fd24d44c5..03dee4030c 100644
--- a/doc/FAQ.doc
+++ b/doc/FAQ.doc
@@ -313,6 +313,34 @@ may give you some insights on what SimGrid can help you to do and what
 are its limitations. Then you definitely should read the \ref
 MSG_examples. There is also a mailing list: <simgrid-user@lists.gforge.inria.fr>.
 
+\subsection faq_interfaces What is the difference between MSG, SimDag, and GRAS? Do they serve the same purpose?
+
+It depend on how you define "purpose", I guess ;)
+
+They all allow you to build a prototype of application which you can run
+within the simulator afterward. They all share the same simulation kernel,
+which is the core of the SimGrid project. They differ by the way you express
+your application.
+
+With SimDag, you express your code as a collection of interdependent
+parallel tasks. So, in this model, applications can be seen as a DAG of
+tasks. 
+
+With both GRAS and MSG, your application is seen as a set of communicating
+processes, exchanging data by the way of messages and performing computation
+on their own.
+
+The difference between both is that MSG is somehow easier to use, but GRAS
+is not limitated to the simulator. Once you're done writing your GRAS code,
+you can run your code both in the simulator or on a real platform. For this,
+there is two implementations of the GRAS interface, one for simulation, one
+for real execution. So, you just have to relink your code to chose one of
+both world. 
+
+Another difference is that GRAS benefits of a much more comprehensive
+documentation than MSG, largely offsetting its allegated difficulty of
+use (IMHO). A good starting point is the \ref GRAS_tut.
+
 \subsection faq_generic Building a generic simulator
 
 Please read carefully the \ref MSG_examples. You'll find in \ref
@@ -762,10 +790,10 @@ PERIODICITY 1.0
 20.0 0.9
 \endverbatim
 
-At time 0, our CPU will deliver 100 Mflop/s. At time 11.0, it will
-deliver only 50 Mflop/s until time 20.0 where it will will start
-delivering 90 Mflop/s. Last at time 21.0 (20.0 plus the periodicity
-1.0), we'll be back to the beginning and it will deliver 100Mflop/s.
+At time 0, our CPU will deliver 100 flop/s. At time 11.0, it will
+deliver only 50 flop/s until time 20.0 where it will will start
+delivering 90 flop/s. Last at time 21.0 (20.0 plus the periodicity
+1.0), we'll be back to the beginning and it will deliver 100 flop/s.
 
 Now let's look at the state file:
 \verbatim
@@ -789,7 +817,7 @@ links. A usual declaration looks like:
 You have at your disposal the following options: bandwidth_file,
 latency_file and state_file. The only difference with CPUs is that
 bandwidth_file and latency_file do not express fraction of available
-power but are expressed directly in Mb/s and seconds.
+power but are expressed directly in bytes per seconds and seconds.
 
 \subsection faq_flexml_bypassing How can I have some C functions do what the platform file does?