X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/0e032ce75eebc9e6f6e2411d1b7937fe0370b16b..b47649fd1bd845d7c3d4c07e4400382570d080db:/doc/FAQ.doc
diff --git a/doc/FAQ.doc b/doc/FAQ.doc
index d438057c5b..e353e180f6 100644
--- a/doc/FAQ.doc
+++ b/doc/FAQ.doc
@@ -492,8 +492,9 @@ 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. Let me recall you the way SimGrid 3 is organized:
+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
________________
@@ -507,15 +508,17 @@ ________________
----------------
\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 it could
-still be brought back if people really need it. Here is how it would fit.
+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 | SG |
+| | MSG | GRAS | SD |
| -------------------|
| | SURF |
| -------------------|
@@ -523,25 +526,19 @@ ______________________
----------------------
\endverbatim
-Re-implementing SG on top of SURF is really straightforward (it only
-requires a little bit of time that I really don't have right now)
-since the only thing that lacks to SURF is the DAG part. But adding it
-to SURF would slow it down and therefore slow MSG and GRAS which is
-not a good thing. However it is really not on the top of our TODO
-list because we have to work on GRAS, and its MPI counterpart, and a
-parallel task model, and ... Anyway, we finally have migrated our CVS
-to gforge so people that are interested by helping on this part will
-have the possibility to do it.
+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_SG_DAG How to implement a distributed dynamic scheduler of DAGs.
Distributed is somehow "contagious". If you start making distributed
-decisions, there is no way to handle DAGs directly anymore (unless I am
-missing something). You have to encode your DAGs in term of communicating
-process to make the whole scheduling process distributed. Believe me, it is
-worth the effort since you'll then be able to try your algorithms in a very
-wide variety of conditions. Here is an example of how you could do that.
-Assume T1 has to be done before T2.
+decisions, there is no way to handle DAGs directly anymore (unless I
+am missing something). You have to encode your DAGs in term of
+communicating process to make the whole scheduling process
+distributed. Here is an example of how you could do that. Assume T1
+has to be done before T2.
\verbatim
int your_agent(int argc, char *argv[] {
@@ -563,57 +560,8 @@ Assume T1 has to be done before T2.
\endverbatim
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 (but it
-prevents you from having "realistic" platform modeling), then you should
-keep using the 2.18.5 versions until somebody has ported SG on top of SURF.
-Note however that SURF will be slower than the old SG to handle traces with
-a lots of variations (there is no trace integration anymore).
-
-\subsection faq_SG_future Will SG come back in the maintained branch one day?
-
-Sure. In fact, we already have thought about a new and cleaner API:
-\verbatim
-void* SG_link_get_data(SG_link_t link);
-void SG_link_set_data(SG_link_t link, void *data);
-const char* SG_link_get_name(SG_link_t link);
-double SG_link_get_capacity(SG_link_t link);
-double SG_link_get_current_bandwidth(SG_link_t link);
-double SG_link_get_current_latency(SG_link_t link);
-
-SG_workstation_t SG_workstation_get_by_name(const char *name);
-SG_workstation_t* SG_workstation_get_list(void);
-int SG_workstation_get_number(void);
-void SG_workstation_set_data(SG_workstation_t workstation, void *data);
-void * SG_workstation_get_data(SG_workstation_t workstation);
-const char* SG_workstation_get_name(SG_workstation_t workstation);
-SG_link_t* SG_workstation_route_get_list(SG_workstation_t src, SG_workstation_t dst);
-int SG_workstation_route_get_size(SG_workstation_t src, SG_workstation_t dst);
-double SG_workstation_get_power(SG_workstation_t workstation);
-double SG_workstation_get_available_power(SG_workstation_t workstation);
-
-SG_task_t SG_task_create(const char *name, void *data, double amount);
-int SG_task_schedule(SG_task_t task, int workstation_nb,
- SG_workstation_t **workstation_list, double *computation_amount,
- double *communication_amount, double rate);
-
-void* SG_task_get_data(SG_task_t task);
-void SG_task_set_data(SG_task_t task, void *data);
-const char* SG_task_get_name(SG_task_t task);
-double SG_task_get_amount(SG_task_t task);
-double SG_task_get_remaining_amount(SG_task_t task);
-void SG_task_dependency_add(const char *name, void *data, SG_task_t src, SG_task_t dst);
-void SG_task_dependency_remove(SG_task_t src, SG_task_t dst);
-e_SG_task_state_t SG_task_state_get(SG_task_t task); /* e_SG_task_state_t can be either SG_SCHEDULED, SG_RUNNING, SG_DONE, or SG_FAILED */
-void SG_task_watch(SG_task_t task, e_SG_task_state_t state); /* SG_simulate will stop as soon as the state of this task is the one given in argument.
- Watch-point is then automatically removed */
-void SG_task_unwatch(SG_task_t task, e_SG_task_state_t state);
-
-void SG_task_unschedule(SG_task_t task); /* change state and rerun.. */
-
-SG_task_t *SG_simulate(double how_long); /* returns a NULL-terminated array of SG_task_t whose state has changed */
-\endverbatim
-
-We're just looking for somebody to implement it... :)
+DAG is really the level of abstraction you want to work with, then you should
+give a try to \ref SD_API.
\section faq_dynamic Dynamic resources and platform building
@@ -772,13 +720,6 @@ Don't assume we never run this target, because we do. Really. Promise!
There is several reasons which may cause the make check to fail on your
machine:
- - You are using a borken compiler.\n
- The symptom may be that the "make check" fails within testsuite/gras
- directory.\n
- For example, the breezy release of Ubuntu comes with a prerelease of the
- 4.0 gcc compiler. This version happens to be completely unusable, and you
- should install a gcc-3.4 compiler and change the /usr/bin/gcc link to let
- it point on /usr/bin/gcc-3.4.
- You are using a borken libc (probably concerning the contextes).\n
The symptom is that the "make check" fails within the examples/msg directory.\n
By default, SimGrid uses something called ucontexts. This is part of the
@@ -796,7 +737,10 @@ machine:
concurently, but 5000 processes is still enough for most purposes, isn't
it?\n
This limitation is the reason why we insist on using this piece of ...
- software even if it's so troublesome.
+ software even if it's so troublesome.\n
+ => use --with-pthread on AMD64 architecture that do not have an
+ ultra-recent libc.
+
- There is a bug in SimGrid we aren't aware of.\n
If none of the above apply, please drop us a mail on the mailing list so
that we can check it out.