6 This page gathers some release notes, to shed light on the recent and current development of SimGrid.
7 Ancient versions are not documented here (the project started in 1998), but in the ChangeLog file only.
9 Version 3.13 (Apr 27. 2016)
10 ---------------------------
12 The Half Release, a.k.a. the Zealous Easter Trim:
14 * Half of the lines of code are gone.
16 * v3.12: 286k lines; v3.13: 142k lines (+ comments)
17 * Experimental untested unused "features" removed
18 * We rewrote several parts in C++ instead of C
20 * Introducing v4 of the XML platform format (many long-due cleanups)
21 * MSG examples fully reorganized (in C and Java)
22 * The S4U interface is rising, toward SimGrid 4
24 * All host manipulations now done in S4U
25 * SimDag was mostly rewritten on top of S4U
26 * MSG & SimDag interfaces mostly unchanged
28 Version 3.14 (Dec 25. 2016)
29 ---------------------------
31 This version (aka, the Christmas Pi) mainly introduces internal reorganization on the way to the future SimGrid 4 version.
32 These changes should be transparent to the users of the MSG, SMPI and SimDag interfaces, even if some buggy features were reworked
33 while some new features were added.
35 Users are expected to switch to this new version at their own pace, as we do not have the manpower to do any bugfixing on the old releases.
36 This version was tested on several Linux distributions, Mac OSX, Windows (restricted to the Java bindings when not using the Ubuntu
37 subsystem of Win10), FreeBSD and NetBSD.
41 * Documentation reorganized and improved
42 * S4U interface further rising, toward SimGrid 4
44 - Routing code rewritten for readability
45 - Virtual Machines almost turned into a plugin
46 - MSG, SimDag, MPI interfaces mostly unchanged
48 * The model-checker now works on NetBSD too.
50 Version 3.14.159 (Dec 29. 2016)
51 -------------------------------
53 The "Christmas Pi (better approximation)" release fixes various small glitches from the 3.14 version.
55 Version 3.15 (March 22 2017)
56 ----------------------------
58 The Spring Release: continuous integration servers become green.
60 * S4U: progress, integrating more parts of SimDag; New examples.
61 * SMPI: Support MPI 2.2; Convert internals to C++ (TBC).
62 * Java: Massive memleaks and performance issues fixed.
63 * Plus the usual bug fixes, cleanups and documentation improvements.
65 Users are expected to switch to this new version at their own pace, as we do not have the manpower to do any bugfixing on the old releases.
66 This version was tested on several Linux distributions, Mac OSX, Windows (restricted to our Java bindings), FreeBSD and NetBSD.
67 None of our 600+ integration tests is known to fail on any of these.
69 Version 3.16 (June 22 2017)
70 ---------------------------
72 The Blooming Spring Release: developments are budding.
74 * S4U: Progress; Activity refcounting is now automatic.
75 * XML: <AS> can now be named <zone> as they should.
76 * SMPI: Further performance improvements; RMA support.
77 * Cloud: Multi-core VMs (do not overcommit them yet)
78 * (+ bug fixes, cleanups and documentation improvements)
80 SMPI performance was further improved, using various OS-level magic to speed up our virtualization of the MPI code to be run. This allowed
81 Tom to run a simulation of HPL involving 10^6 processes... Wow. The dlopen privatization schema should even allows to run your ranks
82 in parallel (even if it's not well tested yet).
84 On the Cloud side, we implemented multi-core VMs, which naturally acts as containers of processes;
85 S4U, the future interface of SimGrid 4.0 also progressed quite a bit.
87 The Storage is currently cleaned up by Fred, and some API changes are to be expected. We are sorry but the exisiting API is so crappy that
88 nobody ever used it, I guess. If you need it, please speak up soon!
90 We renamed AS into NetZone in the XML files (but the old one still work so no rush to update your platform). Since our platforms are
91 hierarchical, it makes no sense to name our zones "Autonomous Systems". Some other documentation pages got updated and modified. If
92 you see a particularly old, misleading or otherwise ugly doc page, please tell us and we'll fix it. Even typo reports are welcome.
94 But most of the work on S4U is not directly visible from the user. We rewamped the whole code of activities (comms, execs, mutex, etc) to
95 not mix the applicative logic (calling test() or wait()) with the object refcounting. Now, you can test your comm object as many time as
96 you want. This change was really intrusive in our internals, and we're not done with restabilizing every bits, but we're on it.
98 Still on the S4U front, we managed to remove a few more XBT modules. We prefer to use the std or boost libraries nowadays, and switching
99 away from the XBT module enable to reduce our maintainance burden. Be warned that XBT will not always remain included in SimGrid.
101 On the infrastructure side, we are trying to setup a regular build task for the main projects using SimGrid, to check that our changes
102 don't break them. The one of StarPU is close to be working (even if not completely). If you want to have your own code tested regularly
103 against the SimGrid git to warn us about breakage that we introduce, please come to us. We can grant you the right to do the needed config
104 in our Jenkins instance.
106 v3.16 also contains the usual bug fixes, such as the jarfile that should now work on Mac OSX (this time for real :) or the Java bindings
107 that should now be clear of any memory leak.
109 In addition, the future already started. We have ongoing changesets that were not ready for 3.16 but should be part of 3.17:
111 - Energy modeling for the network too
112 - New reduction algorithm for the model-checker, based on event folding structures
113 - Multi-model simulations, to specify a differing networking model for each netzone.
115 Version 3.17 (Oct 8. 2017)
116 --------------------------
118 This version is dubbed the "The Drained Leaks release", because almost no known memleak remains, despite testing.
120 * Many many internal cleanups (almost 700 commits since 3.16).
121 * The coverage of our tests is above 80%.
122 * All memleaks but one plugged; A dozen of bugs fixed.
123 * XBT: Further replace XBT with std::* constructs.
125 Version 3.18 (Dec. 24 2017)
126 ---------------------------
128 This is an important version for SimGrid: MSG is now deprecated, and new projects should use S4U instead.
129 There is still some work to do before SimGrid 4: S4U is not ready for SimDag users yet unfortunately. This will come for sure.
131 Main changes in the "Ho Ho Ho! SimGrid 4 beta is coming to town" release:
133 * Convert almost all interesting MSG examples to S4U.
134 * New model: energy consumption due to the network.
135 * Major cleanups in the disk and storage subsystems.
136 * (+ further deprecate XBT, bug fixes and doc improvement)
138 SimGrid 4 *may* be there by the next solstice.
140 Version 3.19 (March 21. 2018)
141 -----------------------------
143 In total, this "Moscovitly-cold Spring" release brings more than 500 commits made by 7 individuals over the last 3 months.
145 * SMPI: Allow to start new actors and ranks after simulation start.
146 * SMPI: Support ICC, better testing on classical proxy apps.
147 * Some kernel headers are now installed, allowing external plugins.
148 * (+ the classical bug fixes and doc improvement)
150 Version 3.19.1 (March 22. 2018)
151 -------------------------------
153 As you may know, we are currently refactoring SimGrid in deep.
154 Upcoming SimGrid4 will be really different from SimGrid3: modular, standard and extensible vs. layered, homegrown and rigid. C++ vs. C.
156 Our goal is to smooth this transition, with backward compatibility and automatic update paths, while still progressing toward SimGrid4.
158 SimGrid remains open during works: The last pure SimGrid3 release was v3.12 while all subsequent versions are usable alpha versions of
159 SimGrid4: Existing interfaces remain unchanged, but the new S4U interface is budding and the internals are deeply reorganized.
161 Since 2015, we work hard to reduce the changes to public APIs. When we need to rename a public library symbol in S4U, we let your compiler
162 issue an explicative warning when you use the deprecated function. These messages remain for four releases, i.e. for one full year,
163 before turning into an error. Starting with v3.15, your can also adapt to API changes with the SIMGRID_VERSION macro, that is defined to
164 31500 for v3.15, to 31901 for v3.19.1 and so on.
166 Starting with this v3.19.1, our commitment to reduce the changes to the public interfaces is extended from the API to the ABI: a program
167 using only MSG or SimDag and compiled against a given version of simgrid can probably be used with a later version of SimGrid without
168 recompilation. We will do our best... but don't expect too much of it, that's a really difficult goal during such profund refactoring.
170 The difference between v3.19 and v3.19.1 is that the former was accidentally breaking the ABI of MSG, while the later is restoring the
173 S4U and kernel APIs will still evolve until SimGrid4, with one-year deprecation warnings as currently. In fact, cleaning up these
174 interfaces and converting them to snake_case() is one release goal of v3.20. But don't worry, we are working to smooth this upgrade path.
176 Once the S4U interface stabilizes, we will provide C bindings on top of it, along with Java and Python ones. Maybe in 3.21 or 3.22.
178 All this is not contradictory with the fact that MSG as a whole is deprecated, because this deprecation only means that new projects
179 should go for MSG but for S4U (to benefit of the future). Despite this deprecation, old MSG projects should still be usable with no change,
180 if we manage to. This is a matter of scientific reproducibility to us.
182 Version 3.20 (June 25 2018)
183 ---------------------------
185 We were rather productive this season, with a total of 837 commits made by 8 individuals over the last 3 months.
187 The most visible change is the S4U API sanitizing. We were using an awful mix of snake_case and CamelCase, and we now use snake_case
188 everywhere. We apologize for the inconvenience, but it's for sake of sanity. Plus, we put portability wrappers in place: you don't have to
189 change your code until v3.24 if you can live with warnings. The MSG API was not changed, of course.
191 The robustness of SMPI continues to improve. It was rock stable, and you can now use it to move the world (if your lever is long enough).
192 We now use several full-scale projects as nightly integration tests: StarPU, BigDFT and also 45 Proxy Apps from various collections.
193 https://github.com/simgrid/SMPI-proxy-apps/
195 Main changes in the "proxy snake_case()" release are:
197 * Sanitize the public API. Compatibility wrappers in place for one year.
198 * More CI: ~45 Proxy Apps + BigDFT + StarPU now tested nightly
199 * MPI: Port the trace replay engine to C++, fix visualization
200 * (+ the classical bug fixes and doc improvement)
202 Version 3.21 (October 5. 2018)
203 ------------------------------
205 This release introduces a few nice features, but the most visible is certainly the new documentation. We started to completely overhaul it.
206 The result is still somewhat in progress, but we feel that it's much better already. We added a complete tutorial on S4U, we started a
207 tutorial on SMPI (still incomplete), we slightly improved the MSG and Java doc, and greatly improved the S4U doc. The section on writing
208 platform files is not converted in the new doc and you'll have to refer to the 3.20 documentation for that (sorry -- time went out).
210 Please give us feedback on this new doc. We want to make it as useful to you as possible, but it's very hard without (constructive) feedback
213 Another big change is that we are currently moving our development from github to framagit. We thought that framagit is a better place to
214 develop an Open Source project as ours. Head now to https://simgrid.org You can still use github if you prefer to use closed source code ;)
216 Main changes of The Restarting Documentation (TRD) release:
218 * Start to overhaul the documentation, and move to Sphinx + RTD.
219 * Allow dynamic replay of MPI apps, controlled by S4U actors
220 * Rewrite the support for auto-restarted actors (was utterly broken)
221 * (+ the classical bug fixes and doc improvement)
223 Version 3.22 (April 2. 2019)
224 ----------------------------
226 The Easter Christmas Release. It was expected from Chrismas, but I was so late that I even managed to miss the spring deadline.
227 This started to be a running joke, so I decided to release it for April 1. But I'm even late for this... Sorry :)
229 * Introducing the Python bindings (still beta)
230 * Doc: SMPI tutorial and platform description ported to RTD
231 * Many internal cleanups leading to some user-level speedups
232 * (+ the classical bug fixes and internal refactorings)
234 The most visible change is certainly the new Python bindings. They are rather experimental yet, and their API may change a bit in future
235 release, but you are already welcome to test them. Many examples are now also available in Python, and the missing ones are on their way.
237 This new bindings further deprecates the old MSG and Java interfaces, which are still provided (and will remain so for a few years at least
238 for the existing users). Their examples are now hidden in deprecated/ Please switch to S4U if you like C++ or to Python if not.
240 This new version also introduce a heavy load of internal cleanups. Fred converted more internals to real C++, with more classes and less
241 procedural cruft. Henri and the other Wrench developpers reported many bugs around activity canceling and resource failures, and we fixed
242 quite a bit of them, but many dark snakes remain in that lake. Fred and Martin converted more doc to the new system (the platform chapter
243 is not finished, but it's not worse than the old one either) while Augustin completed the tutorial for MPI applications. Augustin also
244 added several non-blocking collectives to SMPI, even if Martin finally decided to release right before he could complete the last ones
245 (sorry). We continued cutting on XBT, replacing many functions and modules by their standard counterparts in C++11 or in Boost. We are
246 now using Catch2 for our unit testing. These cleanups may speedup your simulations by something like 10%.
248 Version 3.23 (June 25. 2019)
249 ----------------------------
251 Main change in the "Exotic Solstice" Release:
253 * Support for Solaris and Haiku OSes. Just for fun :)
254 * SMPI: more of MPI3.1; some MPI/IO and async collectives.
255 * Python bindings can now be installed from pip.
256 * (+ many many bug fixes and internal refactorings)
258 Version 3.24 (October 10. 2019)
259 -------------------------------
261 This is the Clean Disk Release:
263 * Introduce an experimental Wifi network model.
264 * Introduce <disk> (cleaner logic than <storage>).
265 * SMPI: Implement Errhandlers and some more MPI3.1 calls.
266 * (+ many bug fixes and internal refactorings)
268 Since June, we continued our new release schema: v3.23.2 got released at some point as an interim release for people wanting something
269 between stable releases (tested on many systems but coming at most once per quarter) and git version (almost always working but you never
270 know). We plan to do so more often in the future, maybe with one interim version per month. Between interim versions, we use an odd
271 version number: v3.23.1 then 3.23.3 until yesterday, and soon 3.24.1.
273 As a user, there is no urgency to upgrade, even if you should not wait more than 9 months to upgrade to another stable version: our policy is
274 to keep backward compatibility and nice upgrading pathes for 3 stable versions. v3.24 removes symbols that got deprecated in v3.20, last
275 year. It deprecates things that will continue to work until v3.27.
277 Speaking of deprecation, we would like to hear from you if you are using the Java bindings under Windows without the WSL installed.
278 Maintaining these native bindings are rather tedious, and we are wondering whether having Java+WSL would be sufficient.
280 In any case, please remember that we like to hear success stories, i.e. reports of the nice things you did with SimGrid. Not only bug
281 reports are welcome :)
283 Version 3.25 (Feb 2. 2020)
284 --------------------------
286 This is the "Palindrom Day" release (today is 02 02 2020).
288 * Improve the Python usability (stability and documentation).
290 - A nasty synchronization bug was ironed out, see full changelog.
291 - Python's doc now integrated with C++ (was organized as a separate tree).
292 - C bindings of S4U were not even part of the doc.
293 - The C++ doc was also improved as methods are now split by theme.
294 - See https://simgrid.org/doc/latest/app_s4u.html#api-reference
296 * Further deprecate MSG: you now have to pass -Denable_msg=ON to cmake.
298 - This is mandatory to use the Java bindings.
299 - OFF by default; The plan is to completely remove MSG by 2020Q4 or 2021Q1.
301 * SimDAG++: Automatic dependencies on S4U activities (experimental)
303 - Some features are already implemented but not all of them
304 - Cannot block an activity until it's scheduled on a resource
305 - No heterogeneous wait_any() that would mix Exec/Comm/Io activities.
306 - See examples/s4u/{io,exec,comm}-dependent for what's already there.
308 Since last fall, we continued to push toward the future SimGrid4 release. This requires to remove MSG and SimDAG once all users have
309 migrated to S4U. The two old interfaces are still here, but this release gives another gentle incitative toward the migration. You now
310 have to explicitly ask for MSG to be compiled in (and it may be removed by Q42020 or Q12021 along with the current Java bindings), and
311 this release proposes a nice S4U replacement for some parts of SimDAG.
313 Since last release also, we had no answer of potential users of the Java bindings on Windows without the WSL installed. We will probably
314 drop this architecture in the near future, then. Simplifying our settings is mandatory to continue to push SimGrid forward.
316 Version 3.26 (Dec 16. 2020)
317 ---------------------------
319 To celebrate the ease of the lockdown in France, we decided to bring another version of SimGrid to the world.
320 This is the "Release" release. Indeed a small contribution to the event, but this release was long overdue anyway.
322 * SMPI: improved support of the proxy apps (including those using petsc)
323 * WiFi: easier description in XML; energy plugin; more examples.
324 * ns-3: Many bug fixes, can use the wifi models too.
325 * (+ many bug fixes, documentation improvement and internal refactoring)
327 Version 3.27 (March 29. 2021)
328 -----------------------------
330 To celebrate the 1176th anniversary of the siege of Paris by Vikings in 845, we just released another version of SimGrid, the Ragnar Release.
331 Yeah, that's a stupid release name, but we already had 4 "spring release" in the past, so we needed another name.
333 * SMPI: can now report leaks and hint about the mallocs and kernels hindering simulation scalability
334 * Doc: Several new sections in the user manual, and start documenting the internals.
335 * S4U: Direct comms from host to host, without mailboxes.
337 In some sense, these changes are just the tip of the iceberg, as we had many refactoring and internal cleanups in this release cycle too. Actually, we have 3
338 main ongoing refactoring that should bring us closer to SimGrid4, that will eventually occur.
340 The first change is dubbed SimDAG++. We want to make it possible to use S4U in the same spirit as SimDAG: centralized scheduling of tasks with dependencies. We
341 need to allow the maestro thread (the one that currently only call engine->run() in the main) to create asynchronous activities, chain them by declaring
342 dependencies, and run the simulation until some event of interest occurs.
344 Previous release introduced inter-activity dependency in s4u, this release introduces direct host-to-host communications (bypassing the mailboxes), but we
345 are not there yet: maestro cannot create asynchronous activities, and there is no way to run the simulation up to a certain point only.
347 The second ongoing refactoring is about the platform creation. Our goal is to provide a C++ API to create your platform from your code, without relying on
348 XML. There is a real possibility that this one will be part of the 3.28 release, in three months. Will see.
350 And the third front is about modernizing the model checker implementation. The current state is very difficult to work with, and we hope that once it's
351 simplified, we will be able to implement more efficient state space reduction techniques, and also allow more synchronization mechanism to be used in the
352 model checker (for now, our dpor algorithm cannot cope with mutexes).
354 In parallel to these refactoring, the work on SMPI stability and robustness peacefully continued. The list of MPI applications that can now work with
355 absolutely no change on top of SMPI really gets impressive... Check it yourself: https://framagit.org/simgrid/SMPI-proxy-apps
357 If you want to speak about it (or other SimGrid-related matter), please join us on Mattermost: https://framateam.org/simgrid/channels/town-square
358 Come! You don't even have to accept the cookies for that!
360 Version 3.28 (July 14. 2021)
361 ----------------------------
363 To celebrate the birthday of Crown Princess Victoria, we just released another version of SimGrid, the "Victoriadagarna" release.
365 * Programmatic platform description (only C++ for now).
366 * New plugin to simplify producer/consumer applications.
367 * MC: new tutorial and associated docker image.
368 * SMPI: improve error handling for incorrect advanced usages.
369 * Many internal cleanups and refactoring to prepare the future.
371 As usual, even the full changelog is only the tip of the iceberg, given the amount of changes in the backstage.
373 This release is the big one for the programmatic platform descriptions, that are now fully usable from C++. XML will not
374 disappear anytime soon, but it is unlikely that we continue developing it in the future. When starting a new project, you should
375 probably go for the programmatic platforms. Or you could wait for the next release, where we hope to introduce the Python bindings of the
376 programmatic platforms. A platform in Python and an application in C++ may provide a better separation of concern (when it will be possible).
378 On the Model-Checking front, the code base did not evolve a lot, but we now provide a brand new tutorial and docker image for those wanting
379 to start using this feature. We are still not done with the refactoring required to unlock the future of Mc SimGrid and still
380 consider that it's less robust than the rest of SimGrid. We're working on it, and you may even find it useful as is anyway.
382 On the SimDag++ front (integrating the SimDAG interface to S4U), some work occurred in the backstage, but we were too busy with the
383 programmatic platforms to make this happen in this release. Maybe next season?
385 On the SMPI front, the work was on improving the usability. SMPI is now better at hinting the problem in buggy and almost-correct
386 applications, and it can assist the user in abstracting parts of the application to improve the simulation performance. Check the SMPI
387 tutorial for details.
389 Finally, we pursued our quest for a better codebase by following the hints of SonarCloud and other static analyzers. This is what it takes
390 to fight the technical debt and ensure that you'll still enjoy SimGrid in a decade. Along the same line, we removed the symbols that were
391 deprecated since 3 releases, as usual.
393 Version 3.29 (not released yet)
394 -------------------------------
396 Release target: September 22. 2021
