From df5fc39f2f638cf1454e29b9a5c2e39af9e1b9ba Mon Sep 17 00:00:00 2001 From: mquinson Date: Sun, 21 Oct 2007 07:46:30 +0000 Subject: [PATCH] Kill a rather outdated section. Most parts are now in the History document, for the curious. The rest, such as "we want to make everything as clean as possible before releasing SimGrid v.3" can certainly be removed now that SimGrid v3 is released since two years. git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk@4836 48e7efb5-ca39-0410-a469-dd3cf9ba447f --- doc/FAQ.doc | 108 +--------------------------------------------------- 1 file changed, 2 insertions(+), 106 deletions(-) diff --git a/doc/FAQ.doc b/doc/FAQ.doc index ec8512bc90..d0f8e1233c 100644 --- a/doc/FAQ.doc +++ b/doc/FAQ.doc @@ -23,7 +23,8 @@ 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. +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 @@ -636,111 +637,6 @@ If you decide that the distributed part is not that much important and that 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 -- 2.20.1