Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
stupid me.
[simgrid.git] / ChangeLog
index b0f3e2d..7e8cb6c 100644 (file)
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,6 +1,104 @@
-SimGrid (3.1.1) unstable; urgency=low
+SimGrid (3.3-cvs) unstable; urgency=low
 
-  GRAS:
+ OVERALL CHANGES:
+
+  * JAVA BINDINGS for MSG (you dreamt of them? We made them)
+    [Malek Cherier & Mt]
+
+  * Introduce the SIMIX module: factorize code between MSG and GRAS.
+    [Bruno Donassolo]
+  
+    Until now, GRAS were using MSG as an interface to SURF. It was
+    quite difficult because both interface have several differences
+    (MSG channels vs GRAS sockets were the most notable point).
+   
+    This also opens the gate to SMPI (which should occur soon) and speed
+    up simulations by to 40% (even if it were not the main goal).
+  
+    ************************************** 
+    *DO NOT MIX 3.2 RESULTS WITH 3.3 ONES* Simix may changes simulations!
+    **************************************
+    The point is that events occuring 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. Sorry for the inconvenience.
+  
+  * Improve the testing infrastructure with tesh. Now a very large part of
+    the code is tested not only by being run but also by checking that the
+    output match an expected output [Mt].
+
+  * Move on to FleXML v1.7 for the embeeded XML parsers. This version
+    is really less memory-demanding, which should allow you to use
+    larger files in SimGrid [AL].
+
+ GRAS:
+  * Convert the PIDs from long int to int to match the MSG ones (and
+    linux ones too) [Mt]
+  * New function: gras_agent_spawn() to launch a new process on
+    current host. Only working in simulation for now. [Mt]
+  * New function: gras_os_hostport() returning a constant form (ie,
+    not needing to be freed) of "gras_os_hostname():gras_os_myport()"
+
+ XBT:
+  * Make the backtrace of exceptions more human readable [Mt]
+  * New module: xbt/str [Mt]
+    a ton of string utility functions (split, join, printf to a newly
+    allocated buffer, trim, etc)
+  * New module: xbt/synchro [Mt]
+    synchronization tools (mutex and conditions) working the same way
+    in simulation and in real life (mainly useful for GRAS, but not
+    only).
+  * New module: xbt/queue [Mt]
+    classical producer/consumer synchronization scheme
+  * xbt_dynar_new_sync() creates a synchronized dynar. All access
+    (using the classical functions will get serialized) [Mt]
+
+ SURF:
+  * Cleaned many thing in surf and fixed a few bugs [AL].
+  * Add a nice command line configuration mechanism to compose models [AL].
+  * Add a new model for parallel tasks (ptask_L07) that is less buggy than
+    the previous one (KCCFLN05). It relies on something that looks like
+    a max-min sharing mechanism but cannot be written as such. A new solver
+    was thus designed [AL].
+  * Add a new solver to lmm. Based on Lagrange optimization and
+    gradient-based descent, it enables to efficiently maximise systems s.a
+  
+     sum f_i(x_i) s.t Ax<= b  with A_{i,j}>=0 and f_i a concave function.
+
+    This solver enables to propose two new network models for TCP Reno and
+    TCP Vegas based on Low's work. These models still need to be fully
+    tested though [Pedro Velho].
+
+ SIMDAG [AL]:
+  * Bug fix in SD_simulate. Now the time bound given as argument is
+    used.
+  * Use the new parallel task model (ptask_L07) as default.
+  * Use the SURF command line configuration mechanism.
+  * 0-size tasks (for synchronization) should now work.
+
+ -- 
+
+SimGrid (3.2) unstable; urgency=low
+
+  OVERALL CHANGES:
+   * Port to windows.
+     We still experience issues on this platform, but we believe that at
+     least MSG is usable.
+
+  GRAS API BREAKAGE (for simplification purpose, sorry):
+   * the gras_msgtype_by_name is not used anymore. Instead of 
+       gras_msg_send(toserver, gras_msgtype_by_name("request"), &request);
+     you can write (and must)
+       gras_msg_send(toserver, "request", &request);
+   - If you still want to pass a gras_msgtype_t to the function (to cache
+     the type and avoid the lookup time), use the gras_msg_send_() variant.
+   - Impacted functions:
+     gras_cb_register, gras_cb_unregister, gras_msg_send, gras_msg_wait,
+     gras_msg_rpccall, gras_msg_rpc_async_call, gras_msg_wait_ext
+   * The callbacks are now expected to return 0 when everything went well
+     (just like the main() function)
+
+  GRAS new features and improvements:
   * New module mecanism where user code can use per process globals [Mt]
     This is similar to gras_userdata_*() functions, but for libraries. It
       factorize some code developped over and over in the examples and AMOK.
@@ -8,13 +106,26 @@ SimGrid (3.1.1) unstable; urgency=low
       converted for now).
   * Fix a vicious bug in the TCP buffering mecanism which leaded to message
     loss when they were small enough to fit into the buffer and sent quickly
-    enough so that they can all get received in one shoot.
+    enough so that they can all get received in one shoot.   
+  * gras_datadesc_by_name and gras_msgtype_by_name: now raise an exception
+    if not found. Use the *_or_null() variant for the old semantic.
+  * In gras_msg_handle, do not discard messages without callback.
+    They are probably messages to be explicitly awaited later (ie, proofs of
+    mis-synchronization in userland since they are sent before being awaited)
+    No big deal usually.
+  * gras_socket_meas_send/recv: semantic changed!
+    The numerical arguments used to be (1) the total amount of data to send
+    and (2) msg_size. This was changed to (1) msg_size and (2) amount of
+    messages. This was need for the fool willing to send more than MAXINT
+    bytes on quite fat pipes.       
        
   AMOK:
   * Do really rename the hostmanagement module to peermanagement. [Mt]
     Ie, rename functions from amok_hm_* to amok_pm_*. This breaks the API,
     but this is rather new and this was documented in the module
     documentation (poor excuses, I admit)
+  * Bandwidth measurement semantic changed! This follows the changes to
+    gras_socket_meas_send/recv explained above.
     
   SIMDAG:
   * A sequential mode has been added to the workstations. When a workstation
@@ -24,6 +135,10 @@ SimGrid (3.1.1) unstable; urgency=low
   SURF:
   * The KCCFLN05 workstation model now handles parallel tasks. It is the
     model for SIMDAG. [Christophe Thiery]
+  * Bug fix in the maxmin solver: Some values were close to 0 instead of
+    equal to 0, which caused some bad behaviors in
+    saturated_constraint_set_update. I now use a threshold mechanism like in
+    surf. [AL]
 
   XBT:
   * When running manually src/testall, you select specific units [Mt]
@@ -39,14 +154,17 @@ SimGrid (3.1.1) unstable; urgency=low
     - "Valgrind spits tons of errors!" [Mt]
     - "How to repport bugs" [Mt]
     - "Cross-compiling a Windows DLL of SimGrid from Linux" [Mt]
+    - "What is the difference between MSG, SimDag, and GRAS?" [Mt]
+    - Communication time measurement within MSG [AL]
+    - I experience weird communication times when I change the latency [AL]
   * GRAS tutorial [Mt]
     It contains:
      - an introduction to the framework and to the used communication model
      - an initiatic tour introducing the most proheminent features:
-       # Part 1: Bases
+       o Part 1: Bases
          . Lesson 0: Installing GRAS
          . Lesson 1: Setting up your own project
-       # Part 2: Message passing
+       o Part 2: Message passing
          . Lesson 2: Exchanging simple messages
          . Lesson 3: Passing arguments to the processes (in SG)
          . Lesson 4: Attaching callbacks to messages
@@ -55,10 +173,15 @@ SimGrid (3.1.1) unstable; urgency=low
          . Lesson 7: Using internal timers
          . Lesson 8: Handling errors through exceptions
          . Lesson 9: Exchanging simple data
+        . Lesson 10: Remote Procedure Calling (RPC)
+        . Lesson 11: Explicitely waiting for messages
+        . Recapping of message passing features in GRAS
+     - A HOWTO section containing:
+       o HOWTO design a GRAS application
        More are due, of course. They will come latter. In the meanwhile, you can 
        check the examples which are still here.
 
- --
+ -- Da SimGrid team <simgrid-devel@lists.gforge.inria.fr> Fri Mar 16 21:11:46 CET 2007
 
 SimGrid (3.1) unstable; urgency=low