Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Allow to compile from the SVN with automake 1.11
[simgrid.git] / ChangeLog
index 339a034..31d1a74 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,57 @@
+SimGrid (3.3.4) unstable; urgency=low
+
+ The "Desktop Grid needs love too" release.
+
+ * Use LV08 as default network model since it gives better accuracy
+    for small messages and shouldn't change things for big ones.
+   Use --cfg=network_model:CM02 to get the previous behavior.
+ * Fix a major regresion from 3.2 where the timeout provided to
+   MSG_task_put_with_timeout() was used as absolute time before which
+   the comm should be done.
+ * Fix a source-level compatibility glitch from 3.2: after defining
+   MSG_USE_DEPRECATED, you can use the old name
+   MSG_task_put_with_time_out() for MSG_task_put_with_timeout()
+ * Allow to compile from the SVN with automake 1.11
+
+ -- Da SimGrid team <simgrid-devel@lists.gforge.inria.fr> 
+
+
+SimGrid (3.3.3) stable; urgency=low
+
+ The "Need for Speed" release.
+ The timings done to validate the 3.3.2 were faulty. 
+ Instead of being 5% faster, it was 15% slower (compared to 3.3.1).
+   
+ The problem was a conversion from a manually handled vector to
+   xbt_dynar_t on the critical path. 
+ xbt_dynar_foreach calls functions, inducing stack management crap.
+
+ We inlined these functions and xbt_dynar_foreach is now breath taking.
+ We also inlined xbt_swag_belong on the way.
+
+ Here are some approximate speedup measurements (on master/slaves
+  simulations lasting between 10s and 20s each):
+   3.3.1                   -> 3.3.2: about same performance
+   3.3.2                   -> 3.3.3: 40% speedup
+   3.3.1                   -> 3.3.3: 40% speedup
+   3.3.1 with inline patch -> 3.3.3: 30% speedup
+   
+ Our reading is that the refactoring which occurred in 3.3.2 made us
+  suffer much more from the xbt_dynar_foreach low performance, but
+  once we solved this, this refactoring proved to be very performance
+  effective. From the 40% speedup, somehow, 10% are due to the
+  inlining and 30% to the refactoring.
+
+ That's a pitty that gcc cannot inline functions placed in other files
+  alone. We have to choose between:
+  - break the encapsulation (by putting private data structures and
+    accessors in headers files to help gcc)
+  - live with low performance 
+  - switch to a decent compiler such as icc (not quite possible).
+
+ -- Da SimGrid team <simgrid-devel@lists.gforge.inria.fr> Thu, 20 Aug 2009 21:21:33 +0200
+
 SimGrid (3.3.2) stable; urgency=low
 
  The "Simplicity does not preceed complexity, but follows it" release.