X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/137552949b7b4a1fbd10665bdf6397405b96dae4..df5fc39f2f638cf1454e29b9a5c2e39af9e1b9ba:/doc/FAQ.doc 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