Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Change the prototype of xbt_thread_create(), sorry.
[simgrid.git] / ChangeLog
index 2630539..fc1e330 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,113 @@
+SimGrid (3.3.4) unstable; urgency=low
+
+ The "Desktop Grid needs love too" release.
+
+ Models improvements:
+ * Major speedup in the maxmin system solving by using lazy evaluation
+   Instead of solving completely the maxmin system at each iteration, 
+     only invalidate (and recompute) the modified parts. 
+   This new feature is enabled in default models but you can try to
+     turn it on with "--cfg:maxmin-selective-update=1" for other models.
+ * Cas01 IMproved as default CPU model
+   This CPU model is the same Cas01 model, but it uses the
+     maxmin-selective-update flag and a heap structure to manage
+     actions on SURF kernel. 
+   It reduces the complexity to find the next action to finish and,
+     consequently, it's faster than the old Cas01.
+   This is the new default CPU model (Cas01).   
+ * Rename the old Cas01 model to Cas01_fullupdate
+   Keep the old cpu model Cas01 with the new name of Cas01_fullupdate.
+   Use "--cfg=cpu_model:Cas01_fullupdate" to use the old default CPU model.
+ * CpuTI (CPU Trace Integration)
+   A new CPU model whose objective is simulate faster when using
+     availability trace files. 
+   Instead of using a full featured, over engineered maxmin system for
+     CPU modeling, this model does the pre-integration of traces files
+     to calculate the amount of CPU power available, and so, executes
+     faster than the old CPU models. 
+   Use "--cfg=cpu_model:CpuTI" to change to this CPU model.
+ * 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.
+   
+   
+         ******************************************
+         *DO NOT MIX 3.3.4 RESULTS WITH OLDER ONES* 
+         ******************************************
+   * The new CPU model may changes simulations!
+     The point is that events occurring at the exact same timestamp
+        are not scheduled in the same order with the old and new 
+        version. This may be enough to completely change the execution
+        of simulations in some cases. 
+   * The new network model will change simulations!
+     This new model is more realistic than the previous one, so you
+       should consider redoing your old experiments with this model.
+     Sorry for the inconvenience.
+
+ MSG:
+ * Port of MSG's mailbox on top of SIMIX network
+   The put/get mechanism was greatly simplified thanks to the new SIMIX module.
+
+ SIMIX:
+ * New SIMIX network module
+   It provides a rendez-vous point (aka mailbox) based send/recv API to perform
+   synchronous communication. 
+   
+ SimDag:
+ * new function SD_daxload(char*) to load a DAX file 
+   (see http://vtcpc.isi.edu/pegasus/index.php/WorkflowGenerator)
+ * Introduce typed tasks. Specify its kind and cost at creation. 
+   At scheduling, just give where it should be placed, and the cost
+   for each involved resource is automatically computed.
+   Existing constructors so far (more to come of course):
+    - SD_task_create_comm_e2e() for end-to-end communication
+    - SD_task_create_comp_seq() for sequential computation
+   Use SD_task_schedulev() / SD_task_schedulel() to schedule them.
+ * new function SD_task_dump() for debuging display
+ * new function SD_task_dotty(task,FILE*) writing to file the info
+   about the task in dotty format
+ * SD_task_dependency_exists() can now cope with having one of its
+   arguments NULL. If so, it tests whether the other argument has any 
+   dependency.
+ * Add getters on list of preceding/following tasks:
+    SD_task_get_parents(task) and SD_task_get_children(task)
+ * Add getters on amount of workstations and list:
+    SD_task_get_workstation_count(t) and SD_task_get_workstation_list(t)
+ * Add getter on task kind: SD_task_get_kind(task)
+ * Update the start_time and finish_time of tasks on completion/failure
+ * Bugfix: Remove task from state swags when destroyed
+ GRAS:
+ * New function: void gras_cpu_burn(double flops) -- a simple CPU burner
+
+ XBT:
+ * New function: xbt_dynar_dopar(dynar,fun) to map a function over the
+   dynar with one separate thread per value of the dynar.
+ * Change the prototype of xbt_thread_create(), sorry. 
+   Added a boolean parameter indicating whether we want to join this
+   thread (used in SG only for now)
+   
+ Bug fixes:
+ * GTNetS wrappers should now be usable again (and betterly tested too)
+ * Fix a major regression 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.
+ * Start to fix the <cluster> tag. 
+   - Internal links should be good now (beside of the loopback, which
+     use the private link instead)
+   - paths to the external world is still rather broken
+   - the <route:multi> tag is just broken. Actually that's brain-dead.
+     We need sth like <route:multi src="myCluster" dst="$*-${myCluster}">
+     to make it less stupid
+   ** Check your platform with teshsuite/simdag/platforms/flatifier **
+ * 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
+ * Fix some problems when using the "start_time" tag in deployment XMLs.
+
+ -- Da SimGrid team <simgrid-devel@lists.gforge.inria.fr> 
+
 SimGrid (3.3.3) stable; urgency=low
 
  The "Need for Speed" release.
 SimGrid (3.3.3) stable; urgency=low
 
  The "Need for Speed" release.
@@ -14,15 +124,16 @@ SimGrid (3.3.3) stable; urgency=low
 
  Here are some approximate speedup measurements (on master/slaves
   simulations lasting between 10s and 20s each):
 
  Here are some approximate speedup measurements (on master/slaves
   simulations lasting between 10s and 20s each):
-   3.3.1                   -> 3.3.2: -15%
-   3.3.2                   -> 3.3.3: +40%
-   3.3.1                   -> 3.3.3: +40%
-   3.3.1 with inline patch -> 3.3.3: +30%
+   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
    
  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.
+  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:
 
  That's a pitty that gcc cannot inline functions placed in other files
   alone. We have to choose between:
@@ -31,7 +142,7 @@ SimGrid (3.3.3) stable; urgency=low
   - live with low performance 
   - switch to a decent compiler such as icc (not quite possible).
 
   - live with low performance 
   - switch to a decent compiler such as icc (not quite possible).
 
- -- Da SimGrid team <simgrid-devel@lists.gforge.inria.fr> 
+ -- Da SimGrid team <simgrid-devel@lists.gforge.inria.fr> Thu, 20 Aug 2009 21:21:33 +0200
 
 SimGrid (3.3.2) stable; urgency=low
 
 
 SimGrid (3.3.2) stable; urgency=low