From: alegrand Date: Thu, 13 Jul 2006 23:27:48 +0000 (+0000) Subject: Updating entry on SG and SimDAG X-Git-Tag: v3.3~2789 X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/commitdiff_plain/6eb19b4485e6ff870b8a3750f9893d61297644da Updating entry on SG and SimDAG git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk@2569 48e7efb5-ca39-0410-a469-dd3cf9ba447f --- diff --git a/doc/FAQ.doc b/doc/FAQ.doc index 08aef210ae..80c32cb52e 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,15 +526,10 @@ ______________________ ---------------------- \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. @@ -569,52 +567,6 @@ 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... :) - \section faq_dynamic Dynamic resources and platform building \subsection faq_platform Building a realistic platform @@ -790,7 +742,8 @@ machine: it?\n This limitation is the reason why we insist on using this piece of ... software even if it's so troublesome.\n - => use --with-pthread on AMD64 architecture + => 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