-========================================================================
--- Wed, Feb 29 16:31:56 2012 +0100
-
-Les fonctions MSG_get_host{number,table} n'existent plus dans les
-dernières versions de SimGrid. Utiliser MSG_hosts_as_dynar à la place.
-
========================================================================
-- Wed, Feb 29 16:16:45 2012 +0100
========================================================================
##### 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
==532== still reachable: 56 bytes in 1 blocks
========================================================================
--- Wed, Mar 9 08:24:40 2011 +0100
-
-Comment expliquer ces différences entre SG 3.5 et SG svn ?
-
-$ ./loba platform.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD
-[Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data
-[Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data
-[Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data
-[Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data
-[Fafard 2579.229566] [comm/DEBUG] received LOAD: 366.211 from Bourassa
-[Fafard 2605.989948] [comm/DEBUG] received LOAD: 20.0806 from Bourassa
-[Fafard 2612.318155] [comm/DEBUG] received LOAD: 4.74548 from Bourassa
-[Fafard 2616.450666] [comm/DEBUG] received LOAD: 3.09753 from Bourassa
-
-$ ./loba-dev platform_dev.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD
-[Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data
-[Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data
-[Fafard 1519.035900] [comm/DEBUG] received LOAD: 366.211 from Bourassa
-[Fafard 1519.035900] [comm/DEBUG] send LOAD: 282.074 to Ginette_data
-[Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data
-[Fafard 1629.312931] [comm/DEBUG] received LOAD: 20.0806 from Bourassa
-[Fafard 1629.312931] [comm/DEBUG] received LOAD: 4.74548 from Bourassa
-[Fafard 1629.312931] [comm/DEBUG] send LOAD: 6.19507 to Ginette_data
-[Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data
-[Fafard 1898.705676] [comm/DEBUG] received LOAD: 3.09753 from Bourassa
-[Ginette 1932.076243] [comm/DEBUG] received LOAD: 282.074 from Fafard
-[Ginette 1940.343540] [comm/DEBUG] received LOAD: 6.19507 from Fafard
-
--- Thu, Mar 24 16:03:24 2011 +0100
-
-Probablement par un bug dans SG 3.5.
-
-========================================================================
--- Thu, Jan 27 17:15:02 2011 +0100
-
-Il semblerait qu'il y ait un bug dans SG 3.5, et qu'on ne puisse pas
-utiliser MSG_comm_waitany() pour l'émetteur *et* le récepteur sans
-risquer d'interblocage.
-
-Le problème devrait être contourné correctement depuis le commit
-cd6b253 Use MSG_comm_waitall for communicator::flush(true).
-
-========================================================================
--- Thu, Jan 27 17:15:02 2011 +0100
-
-Avec SG 3.5, les communications doivent être détruites dès que
-possible avec MSG_comm_destroy(). Si ce n'est pas fait, la simulation
-peut être extrêmement ralentie.
-
-Le problème devrait être contourné correctement depuis le commit
-404a8d5 Do not call flush automatically in communcator::send...
-
-========================================================================
