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.
+tasks. This is the interface of choice for people wanting to port old
+code designed for SimGrid v1 or v2 to the lastest framework.
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
In summary, the following commands will checkout the SVN, regenerate the
configure script and friends, configure SimGrid and build it.
-\verbatim svn checkout svn://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk
-mv trunk simgrid
+\verbatim svn checkout svn://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk simgrid
cd simgrid
./bootstrap
./configure --enable-maintainer-mode --prefix=<where to install SimGrid>
DAG is really the level of abstraction you want to work with, then you should
give a try to \ref SD_API.
-\subsubsection faq_SG Where has SG disappeared?
-
-OK, it's time to explain what's happening to the SimGrid project. Let's
-start with a little bit of history.
-
-* Historically, SimGrid was a low-level toolkit for scheduling with
-classical models such as DAGs. That was SimGrid v.1.* aka SG, written
-by Henri Casanova. I (Arnaud) had been using it in its earliest
-versions during an internship at UCSD.
-
-Then we have realized that encoding distributed algorithm in SG was a
-real pain.
-
-* So we have built MSG on top of SG and have released SimGrid v.2.*. MSG
-offered a very basic API to encode a distributed application easily.
-However encoding MSG on top of SG was not really convenient and did not
-use the DAG part since the control of the task synchronization was done
-on top of MSG and no more in SG. We have been playing a little bit with
-MSG. We have realized that:
-
- \li 1) the platform modeling was quite flexible and could be "almost"
- automated (e.g. using random generator and post-annotations);
-
- \li 2) SG was the bottleneck because of the way we were using
- it. We needed to simulate concurrent transfers, complex load
- sharing mechanisms. Many optimizations (e.g. trace integration)
- were totally inefficient when combined with MSG and made extending SG
- to implement new sharing policies, parallel tasks models, or failures
- (many people were asking for these kind of features) a real pain;
-
- \li 3) the application modeling was not really easy. Even though the
- application modeling depends on people's applications, we thought
- we could improve things here. One of our target here was realistic
-distributed applications ranging from computer sensor networks like
-the NWS to peer-to-peer applications;
-
-* So we have been planning mainly two things for SimGrid 3:
-
- \li 1) I have proposed to get rid of SG and to re-implement a new kernel
- that would be faster and more flexible. That is what I did in the
-end of 2004: SURF. SURF is based on a fast max-min linear solver
-using O(1) data-structures. I have quickly replaced SG by SURF in
-MSG and the result has been that on the MSG example, the new
-version was more than 10 times faster while we had gain a lot of
-flexibility. I think I could still easily make MSG faster but I
-have to work on MSG now (e.g. using some of the O(1)
-data-structures I've been using to build SURF) since it has become
-the bottleneck. Some MSG functions have been removed from the API
-but they were mainly intended to build the platform by hand (they
-had appeared in the earliest versions of MSG) and were therefore
-not useful anymore since we are providing a complete mechanism to
-automatically build the platform and deploy the agents on it.;
-
- \li 2) GRAS is a new project Martin and I have come up with. The idea is
-to have a programming environment that let you program real
-distributed applications while letting you the ability to run it in
-the simulator without having to change the slightest line of your
-code. From the simulation point of view, GRAS performs the
-application modeling automatically... Up until now, GRAS works on
-top MSG for historical reasons but I'm going to make it work
-directly on top of SURF so that it can use all the flex and the
-speed provided by SURF.
-
-Those two things are working, but we want to make everything as clean as
-possible before releasing SimGrid v.3.
-
-So what about those nice DAGs we used to have in SimGrid v.1.? They're
-not anymore in SimGrid v.3. At least not in their original form... Let
-me recall you the way SimGrid 3 is organized:
-
-\verbatim
-________________
-| User code |
-|______________|
-| | MSG | GRAS |
-| -------------|
-| | SURF |
-| -------------|
-| XBT |
-----------------
-\endverbatim
-
-XBT is our tool box and now, you should have an idea of what the other
-ones are. As you can see, the primitive SG is not here
-anymore. However we have written a brand new and cleaner API for this
-purpose: \ref SD_API. It is built directly on top of SURF and provides
-an API rather close to the old SG:
-
-\verbatim
-_________________________
-| User code |
-|________________________|
-| | MSG | GRAS | SimDag |
-| -----------------------|
-| | SURF |
-| -----------------------|
-| XBT |
---------------------------
-\endverbatim
-
-The nice thing is that, as it is writen on top of SURF, it seamlessly
-support DAG of parallel tasks as well as complex communications
-patterns. Some old codes using SG are currently under rewrite using
-\ref SD_API to check that all needful functions are provided.
-
\subsection faq_MIA_generic Generic features
\subsubsection faq_more_processes Increasing the amount of simulated processes
\subsection faq_platform Platform building and Dynamic resources
-\subsubsection faq_platform Building a realistic platform
+\subsubsection faq_platform_example Where can I find SimGrid platform files?
+
+There is several little examples in the archive, in the examples/msg
+directory. From time to time, we are asked for other files, but we
+don't have any at hand right now.
+
+We do have a description of the Grid'5000 platform, but because of
+some flaws in the current formalism, this file is actually 500Mb,
+which is ways too big to be used in the parser. We have an internship
+currently working on xml syntax improvements which will allow to
+reduce the size of this file and release it.
+
+Once it's done, we plan to model manually other existing platforms the
+same way we did for G5K and also release those files in some sort of
+SimGrid platform catalog project.
-We can speak more than an hour on this subject and we still do not have
-the right answer, just some ideas. You can read the following
+\subsubsection faq_platform_alnem How can I automatically map an existing platform?
+
+We are working on a project called ALNeM (Application-Level Network
+Mapper) which goal is to automatically discover the topology of an
+existing network. Its output will be a platform description file
+following the SimGrid syntax, so everybody will get the ability to map
+their own lab network (and contribute them to the catalog project).
+This tool is not ready yet, but it move quite fast forward. Just stay
+tuned.
+
+\subsubsection faq_platform_synthetic Generating synthetic but realistic platforms
+
+The third possibility to get a platform file (after manual or
+automatic mapping of real platforms) is to generate synthetic
+platforms. Getting a realistic result is not a trivial task, and
+moreover, nobody is really able to define what "realistic" means when
+speaking of topology files. You can find some more thoughts on this
+topic in these
<a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">slides</a>.
-It may give you some hints. You can also have a look at the
-<tt>tools/platform_generation/</tt> directory. There is a perl-script
-we use to annotate a Tiers generated platform.
-\subsubsection faq_SURF_dynamic Building a dynamic platform, with resource availability
+If you are looking for an actual tool, there we have a little tool to
+annotate Tiers-generated topologies. This perl-script is in
+<tt>tools/platform_generation/</tt> directory of the SVN. Dinda et Al.
+released a very comparable tool, and called it GridG.
+
+\subsubsection faq_SURF_dynamic Expressing dynamic resource availability in platform files
A nice feature of SimGrid is that it enables you to seamlessly have
resources whose availability change over time. When you build a
bandwidth_file and latency_file do not express fraction of available
power but are expressed directly in bytes per seconds and seconds.
-\subsubsection faq_platform_multipath Is it possible to have several paths between two given hosts?
+\subsubsection faq_platform_multipath How to express multipath routing in platform files?
-The answer is no, unfortunately. Let's consider the following platform
-file:
+It is unfortunately impossible to express the fact that there is more
+than one routing path between two given hosts. Let's consider the
+following platform file:
\verbatim
<route src="A" dst="B">
\endverbatim
This makes sure that data from C to A go through B where data from A
-to C go directly. Do not worry about realism of such settings since
-we've seen ways more weird situation in real settings.
+to C go directly. Don't worry about realism of such settings since
+we've seen ways more weird situation in real settings (in fact, that's
+the realism of very regular platforms which is questionable, but
+that's another story).
\subsubsection faq_flexml_bypassing Bypassing the XML parser with your own C functions
