aivika-distributed 1.1.1 → 1.1.2

raw patch · 2 files changed

+17/−11 lines, 2 filesPVP ok

version bump matches the API change (PVP)

API changes (from Hackage documentation)

Files

• CHANGELOG.md +5/−0
• aivika-distributed.cabal +12/−11

@@ -1,4 +1,9 @@ +Version 1.1.2+-----++* Updated the main page documentation with new recommendations.+ Version 1.1.1 ----- 

@@ -1,5 +1,5 @@ name:            aivika-distributed-version:         1.1.1+version:         1.1.2 synopsis:        Parallel distributed discrete event simulation module for the Aivika library description:     This package extends the aivika-transformers [1] package and allows running parallel distributed simulations.@@ -8,7 +8,7 @@     .     Moreover, this package uses the author's modification that allows recovering the distributed     simulation after temporary connection errors whenever possible. For that, you have to enable explicitly -    the recovering mode and enable monitoring all logical processes including the specialized Time Server process +    the recovering mode and enable the monitoring of all logical processes including the specialized Time Server process      as it is shown in one of the test examples included in the distribution.     .     With the recovering mode enabled, you can try to build a distributed simulation using ordinary computers connected@@ -31,23 +31,24 @@     The distributed simulation module is slower up to 8-15 times in comparison with the sequential aivika [2] simulation      library using the equivalent sequential models. The lower estimation in 8 times is likely to correspond to complex      models. The upper estimation in 15 times will probably correspond to quite simple event-oriented and process-oriented -    models, where the sequential module can be exceptionally fast. +    models, where the sequential module can be exceptionally fast. At the same time, the message passing between +    the logical processes can dramatically decrease the speed of distributed simulation, especially if they cause rollbacks. +    Thus, much depends on the distributed model itself.     .-    Note that you can run up to 7 parallel logical processes on a single 8-core processor computer and run the Time Server -    process too. On a 36-core processor, you can launch up to 35 logical processes simultaneously.-    . -    At the same time, the message passing between the logical processes can dramatically decrease the speed of distributed -    simulation, especially if they cause rollbacks. Thus, much depends on the distributed model itself.+    When residing the logical processes in a computer with multi-core processor, you should follow the next recommendations. +    You should reserve at least 1 core for each logical process, or even reserve 2 cores if the logical process extensively +    sends and receives messages. Also you should additionally reserve at least 1 or 2 cores for each computational node. +    These additional processor cores will be used by the GHC run-time system that includes the garbage collector as well. +    The Aivika distributed module creates a huge amount of short-living small objects. Therefore, the garbage collector +    needs at least one core to utilize efficiently these objects.     .-    Finally, you can use the following test model [4] as an example.+    You should compile your code with options -O2 and -threaded, but then launch it with run-time options +RTS -N.     .     \[1] <http://hackage.haskell.org/package/aivika-transformers>     .     \[2] <http://hackage.haskell.org/package/aivika>     .     \[3] <http://www.aivikasoft.com>-    .-    \[4] <https://github.com/dsorokin/aivika-distributed-test>     . category:        Simulation license:         BSD3