======================================================================== -- Wed, Feb 29 16:16:45 2012 +0100 Les exécutions parallèles donnent des résultats différents. Pourquoi ? ======================================================================== ##### MOSTLY RESOLVED BUGS COME AFTER THIS ############################# ======================================================================== -- Wed, 02 May 2018 10:48:05 +0200 Fort ralentissement d'un facteur 2, voire plus, avec les versions récentes de SimGrid (3.18, 3.19.1). Il semblerait que l'utilisation d'exceptions en cas de timeout dans les simcalls soit coûteuse. À vérifier. -- Mon, 07 May 2018 16:05:49 +0200 Les exceptions ne sont plus utilisées depuis le commit 8efeb3a6aa2c201800a3ba19416ea9728af3bff6 (Stop using costly exceptions on timeout for simix synchros). Le ralentissement restant dans lmm_solve() semble venir essentiellement du commit f3677661714bf6122d678071c0bd44141417be14 (Fix bug #17132 (surf.c:366: The Impossible Did Happen (yet again))). ======================================================================== -- Wed, 02 May 2018 10:44:41 +0200 Ne fonctionne pas avec les versions de SimGrid de 3.8 à 3.12 inclus : la simulation ne démarre pas (le thread "compute" déployé automatiquement n'est pas exécuté). Le problème est introduit par le commit e6d1ca27d8852f9922141ea15eae6b339c2d2bc7 (Completely remove surfxml_callback. Clean the way to create arg for the process.), puis corrigé par le commit bb66fe3993929c5d1b25e4982502869d725cefd7 ([platf] Kill sg_process_cb). Avec des versions plus récentes, plante après la fin de la simulation (SIGSEGV) pour les versions de SimGrid de 3.13 à 3.17 inclus. ======================================================================== -- Mon, Feb 27 13:26:08 2012 +0100 Les variables globales process::total_load_* ne sont pas protégées contre les accès concurrents. Il n'est donc pas possible actuellement d'exécuter les simulations en parallèle (--cfg=contexts/nthreads). -- Wed, Feb 29 15:54:31 2012 +0100 Corrigé en partie. Il reste quelques "fixme: get locked?" à régler (ou pas). ======================================================================== -- Fri, May 20 17:01:33 2011 +0200 Il faut réviser l'utilisation du mutex entre le thread d'équilibrage et le thread de calcul. Il semble gardé beaucoup trop longtemps. -- Tue, May 24 14:55:59 2011 +0200 Bon, une partie du problème est rectifiée par le commit 48de954 Stop locking the mutex on data_receive. Pour le reste, je pense maintenant que ça ne gêne pas, au moins dans le simulateur. Pour faire bien, il faudrait plus séparer les deux threads d'équilibrage et de calcul, et faire en sorte que chacun garde un cache des données globales partagées. Il suffirait alors de synchroniser ces caches à chaque itération. Les données partagées sont essentiellement les données des voisins : load, to_send et debt. ======================================================================== -- Tue, Apr 19 17:48:39 2011 +0200 Valgrind détecte une fuite de mémoire liée à un appel à backtrace. Le problème semble être indépendant de SimGrid et peut être reproduit avec le code suivant (NB: l'équivalent, compilé avec gcc ne génère pas d'erreur). ,---- | #include | #include | int main() | { | void *buffer[64]; | int size = -1; | size = backtrace(buffer, sizeof buffer / sizeof buffer[0]); | std::cerr << "backtrace() returned " << size << "\n"; | } `---- ==532== HEAP SUMMARY: ==532== in use at exit: 56 bytes in 1 blocks ==532== ... ==532== LEAK SUMMARY: ==532== ... ==532== still reachable: 56 bytes in 1 blocks ========================================================================