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.