1 /*! \page history History of SimGrid
3 \htmlinclude .history.doc.toc
5 Many people have asked about the origins of the SimGrid project, about
6 the history of its development up to now, and about plans for the future.
7 Here it is, in (perhaps excruciating) details.
9 \section history_sg SimGrid v1
11 In 1999 Henri Casanova joined the AppLeS research group in the Computer
12 Science and Engineering Department at the University of California at San
13 Diego, as a post-doc. The AppLeS group, led by Francine Berman, focused
14 mostly on the study of practical scheduling algorithms for parallel
15 scientific application on heterogeneous, distributed computing platforms.
16 Shortly after Henri joined the group he faced the need to run simulation
17 instead of or in addition to merely running real-world experiments. At
18 that time Arnaud Legrand, a 1st year graduate student at Ecole Normale
19 Superieure de Lyon, France, spent 2 months in the summer in the AppLeS
20 group as a visiting student. He worked with Henri that summer on a research
21 project as part of which he implemented an ad-hoc simulator.
23 After Arnaud left UCSD, Henri realized that most likely every researcher
24 in the AppLeS group would eventually need to run simulations, and that they
25 would most likely all end up rewriting the same code at one point or
26 another. He took apart the simulator that Arnaud had developed, an packaged
27 it as a more generic simulation framework with a simple API, and called it
28 SimGrid v1.0 (a.k.a. SG). This version was simple, and in retrospect a bit
29 naive. However, it was surprisingly useful to study "centralized"
30 scheduling (e.g., off-line scheduling of a DAG on a heterogeneous set of
31 distributed compute nodes). SimGrid v1.0 was described in "SimGrid: A
32 Toolkit for the Simulation of Application Scheduling, by Henri Casanova, in
33 Proceedings of CCGrid 2001". Henri became the first user of SimGrid and
34 used it for several research projects from then on.
36 \section history_msg SimGrid v2
38 By 2001 time Arnaud was engaged in his Ph.D. thesis work and started
39 studying "decentralized" scheduling heuristics, that is ones in which
40 scheduling decisions are made by more or less autonomous agents that typicaly have only
41 partial knowledge of the applications and/or computing platform. Although
42 simulating decentralized scheduling with SimGrid v1.0 was actually possible
43 (and done by one Ph.D. student at UCSD in fact!), it was extremely cumbersome
44 and limited in scope. So Arnaud built a layer on top of SG, which he
45 called MSG (for Meta-SimGrid). MSG added threads and introduced the
46 concept of independently running simulated processes that performed
47 computations and communication tasks in possibly asynchronous fashion. MSG
48 was described in "MetaSimGrid : Towards realistic scheduling simulation of
49 distributed applications, by Arnaud Legrand and Julien Lerouge, LIP
50 Research Report". This resulted in the following layered architecture:
59 With Henri and some of his students using SG and Arnaud using MSG, the
60 project started having a (tiny) user base. It was time to be more ambitious
61 and to address one of the key limitation of SG: its inability to simulate
62 multi-hop network communications realistically. In the Summer 2003 Loris
63 Marchal, a 1st year graduate student at Ecole Normale Superieure, came to
64 UCSD to work with Henri. During that summer, based on results in the TCP modeling
65 literature, he implemented a macroscopic network model as part of SG. This
66 model dramatically increased the level of realism of SimGrid simulations and
67 was initially described in: "A Network Model for Simulation of Grid
68 Applications, by Loris Marchal and Henri Casanova, LIP research report". By
69 the end of 2003 the work at UCSD and at Ecole Normale was merged in what
70 became SimGrid v2, as described in: "Scheduling Distributed Applications:
71 the SimGrid Simulation Framework, by Henri Casanova, Arnaud Legrand, and
72 Loris Marchal, in Proceedings of CCGrid 2003".
74 \section history_gras SimGrid v3
76 SimGrid v2, with its much improved features and capabilities, garnered a
77 larger user base and many friends and collaborators of Arnaud and Henri
78 started using it for their research. On these friends was Martin Quinson,
79 then a Ph.D. student at Ecole Normale Superieure, who was working in the
80 area of distributed resource monitoring systems. As part of his Ph.D.
81 Martin attempted to develop a network topology discovery tool and quickly
82 found out that it was difficult and required prototyping in simulation.
83 Faced with the perspective of first implementing a throw-away prototype in
84 simulation and then reimplementing the whole thing for production, Martin
85 started working on a framework that would easily compile the same code in
86 "simulation mode" or in "real-world mode". He found this ability
87 to be invaluable when developing distributed systems and built his framework,
88 called GRAS, on top of MSG (for the simulation mode) and on top of the
89 socket layer (for the real-world mode). GRAS is described in "GRAS: A
90 Research & Development Framework for Grid and P2P Infrastructures, by
91 Martin Quinson, in Proceedings of PDCS 2006". This led to the following
92 layered software architecture:
94 (user code for either SG, MSG or GRAS)
95 -----------------------------
97 | | -------------------
98 | | |GRAS S | |GRAS R |
99 | | --------- ---------
101 | --------------| ---------
105 At this point, with more users running more complex
106 simulations, it became clear that the initial SG
107 foundation inherited from SimGrid v1 was too limiting in terms
108 of scalability and performance. In 2005 Arnaud took the bull by the horns
109 and replaced SG with a new simulation engine called SURF, thus removing the
110 SG API. Users reported acceleration factors of up to 3 orders of magnitude
111 when going from SG to SURF. Furthermore, SURF is much more extensible than
112 SG ever was and has enabled the evolution of simulation models used by SimGrid.
113 Although it made sense at the time to re-implement GRAS on top of
114 SURF, it was never accomplished due to the "too many things to do not
115 enough time" syndrome. Martin added a layer on top of GRAS called AMOK, to
116 implement high-level services needed by many distributed applications, thus
117 leading to the new overall layered architecture:
119 (user code for either MSG or GRAS -- using AMOK or not)
122 -------------------------
124 | -------------------
125 | |GRAS S | |GRAS R |
126 | --------- ---------
128 --------------| ---------
132 This architecture culminated in SimGrid v3! One development worth mentioning
133 is that of SimDAG, written by Christophe Thiery during an Internship with
134 Martin Quinson. Many users indeed had asked functionality similar to what
135 the SG API provided in SimGrid v1 and v2, to study centralized scheduling
136 without all the power of the MSG API. SimDAG provides an API
137 especially for this purpose and was integrated in SimGrid v3.1, leading
138 to the following layered architecture:
140 (user code for either SimDag, MSG or GRAS)
143 --------------------------------
145 | | -------------------
146 | | |GRAS SG| |GRAS RL|
147 | | --------- ---------
148 |SimDag| MSG | |sockets|
149 |--------------------| ---------
151 ----------------------
153 SimGrid 3.2, the current publicly available version as this document is
154 being written, implements the above architecture and also provides a
155 (partial) port to the Windows operating system.
157 \section history_ongoing Ongoing Work
159 As the project advances, it becomes increasingly clearer that there is a need
160 for an intermediate layer between the base simulation engine, SURF, and higher
161 level APIs. In the previously shown software architecture MSG plays the role
162 of an intermediate layer between SURF and GRAS, but is itself a high-level API,
163 which is not very good design. Bruno Donassolo, during an internship with
164 Arnaud, has developed an intermediate layer called SIMiX, and both GRAS
165 and MSG are being rewritten on top of it.
167 Another development is that of SMPI, a framework to run unmodified MPI
168 applications in either simulation mode or in real-world mode (sort of GRAS
169 for MPI). The development of SMPI, by Mark Stillwell who works with Henri,
170 is being greatly simplified thanks to the aforementioned SIMiX layer.
171 Finally, somewhat unrelated, is the development of Java bindings for the
172 MSG API by Malek XXX who works with Martin. The current software
173 architecture thus looks as follows:
175 (user code for either SimDAG, MSG, GRAS, or MPI)
176 ----------------------------------
179 |SimDag| MSG | GRAS | SMPI | (Note that GRAS and SMPI also run on top of
180 | --------------------------- sockets and MPI, not shown on the figure)
182 ----------------------------------
184 ----------------------------------
186 While the above developments are about adding simulation functionality, a
187 large part of the research effort in the SimGrid project relates to
188 simulation models. These models are implemented in SURF, and Arnaud has
189 refactored SURF to make it more easily extensible so that one can
190 experiment with different models, in particular different network models.
191 Pedro Velho, who works with Arnaud, is currently experimenting with several
192 new network models. Also, Kayo Fujiwara, who works with Henri, has
193 interfaced SURF with (a patched version of) the GTNetS packet-level
196 The current architecture in the CVS tree at the time this document is
197 being written is as follows:
199 ----------------------------------
202 |SimDag| MSG | GRAS | SMPI | (Note that GRAS and SMPI also run on top of
203 | | | ------- | sockets and MPI, not shown on the figure)
205 | ---------------------------
207 ----------------------------------
209 ----------------------------------
210 | SURF kernel | | GTNetS |
211 | (several models) | | |
212 -------------------- ----------
214 \section history_future Future Directions
216 The primary short-term future direction is to develop a distributed version of
217 SIMiX to increase the scalability of simulations in terms of memory. This can be done
218 using the GRAS "real world" functionality to run SIMiX in a distributed fashion
219 across multiple hosts, thus allowing to run simulations that are not
220 limited by the amount of memory on a single host. The simulation itself
221 would still be centralized and sequential, meaning that a single simulated
222 process would run at a time. Bruno Donassolo is currently working on this
223 idea, which is currently called SMURF.
225 Longer-term plans include:
227 \li More development in AMOK
228 \li Component for simulation visualization
229 \li Model-checking in GRAS
230 \li True parallel simulation
233 One of the constant challenge in this project is its duality: it is a
234 useful tool for scientists (hence our efforts on APIs, portability,
235 documentation, etc.), but is it also a scientific project in its own right
236 (so that we can publish papers).
