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:
58 -----------\endverbatim
60 With Henri and some of his students using SG and Arnaud using MSG, the
61 project started having a (tiny) user base. It was time to be more ambitious
62 and to address one of the key limitation of SG: its inability to simulate
63 multi-hop network communications realistically. In the Summer 2003 Loris
64 Marchal, a 1st year graduate student at Ecole Normale Superieure, came to
65 UCSD to work with Henri. During that summer, based on results in the TCP modeling
66 literature, he implemented a macroscopic network model as part of SG. This
67 model dramatically increased the level of realism of SimGrid simulations and
68 was initially described in: "A Network Model for Simulation of Grid
69 Applications, by Loris Marchal and Henri Casanova, LIP research report". By
70 the end of 2003 the work at UCSD and at Ecole Normale was merged in what
71 became SimGrid v2, as described in: "Scheduling Distributed Applications:
72 the SimGrid Simulation Framework, by Henri Casanova, Arnaud Legrand, and
73 Loris Marchal, in Proceedings of CCGrid 2003".
75 \section history_gras SimGrid v3
77 SimGrid v2, with its much improved features and capabilities, garnered a
78 larger user base and many friends and collaborators of Arnaud and Henri
79 started using it for their research. On these friends was Martin Quinson,
80 then a Ph.D. student at Ecole Normale Superieure, who was working in the
81 area of distributed resource monitoring systems. As part of his Ph.D.
82 Martin attempted to develop a network topology discovery tool and quickly
83 found out that it was difficult and required prototyping in simulation.
84 Faced with the perspective of first implementing a throw-away prototype in
85 simulation and then reimplementing the whole thing for production, Martin
86 started working on a framework that would easily compile the same code in
87 "simulation mode" or in "real-world mode". He found this ability
88 to be invaluable when developing distributed systems and built his framework,
89 called GRAS, on top of MSG (for the simulation mode) and on top of the
90 socket layer (for the real-world mode). GRAS is described in "GRAS: A
91 Research & Development Framework for Grid and P2P Infrastructures, by
92 Martin Quinson, in Proceedings of PDCS 2006". This led to the following
93 layered software architecture:
96 (user code for either SG, MSG or GRAS)
97 -----------------------------
99 | | -------------------
100 | | |GRAS S | |GRAS R |
101 | | --------- ---------
103 | --------------| ---------
105 -------------------\endverbatim
107 At this point, with more users running more complex
108 simulations, it became clear that the initial SG
109 foundation inherited from SimGrid v1 was too limiting in terms
110 of scalability and performance. In 2005 Arnaud took the bull by the horns
111 and replaced SG with a new simulation engine called SURF, thus removing the
112 SG API. Users reported acceleration factors of up to 3 orders of magnitude
113 when going from SG to SURF. Furthermore, SURF is much more extensible than
114 SG ever was and has enabled the evolution of simulation models used by SimGrid.
115 Although it made sense at the time to re-implement GRAS on top of
116 SURF, it was never accomplished due to the "too many things to do not
117 enough time" syndrome. Martin added a layer on top of GRAS called AMOK, to
118 implement high-level services needed by many distributed applications, thus
119 leading to the new overall layered architecture:
122 (user code for either MSG or GRAS -- using AMOK or not)
125 -------------------------
127 | -------------------
128 | |GRAS S | |GRAS R |
129 | --------- ---------
131 --------------| ---------
133 ---------------\endverbatim
135 This architecture culminated in SimGrid v3! One development worth mentioning
136 is that of SimDAG, written by Christophe Thiery during an Internship with
137 Martin Quinson. Many users indeed had asked functionality similar to what
138 the SG API provided in SimGrid v1 and v2, to study centralized scheduling
139 without all the power of the MSG API. SimDAG provides an API
140 especially for this purpose and was integrated in SimGrid v3.1, leading
141 to the following layered architecture:
144 (user code for either SimDag, MSG or GRAS)
147 --------------------------------
149 | | -------------------
150 | | |GRAS SG| |GRAS RL|
151 | | --------- ---------
152 |SimDag| MSG | |sockets|
153 |--------------------| ---------
155 ----------------------\endverbatim
157 SimGrid 3.2, the current publicly available version as this document is
158 being written, implements the above architecture and also provides a
159 (partial) port to the Windows operating system.
161 \section history_ongoing Ongoing Work
163 As the project advances, it becomes increasingly clearer that there is a need
164 for an intermediate layer between the base simulation engine, SURF, and higher
165 level APIs. In the previously shown software architecture MSG plays the role
166 of an intermediate layer between SURF and GRAS, but is itself a high-level API,
167 which is not very good design. Bruno Donassolo, during an internship with
168 Arnaud, has developed an intermediate layer called SIMiX, and both GRAS
169 and MSG are being rewritten on top of it.
171 Another development is that of SMPI, a framework to run unmodified MPI
172 applications in either simulation mode or in real-world mode (sort of GRAS
173 for MPI). The development of SMPI, by Mark Stillwell who works with Henri,
174 is being greatly simplified thanks to the aforementioned SIMiX layer.
175 Finally, somewhat unrelated, is the development of Java bindings for the
176 MSG API by Malek Cherier who works with Martin. The current software
177 architecture thus looks as follows:
180 (user code for either SimDAG, MSG, GRAS, or MPI)
181 ----------------------------------
184 |SimDag| MSG | GRAS | SMPI | (Note that GRAS and SMPI also run on top of
185 | --------------------------- sockets and MPI, not shown on the figure)
187 ----------------------------------
189 ----------------------------------\endverbatim
191 While the above developments are about adding simulation functionality, a
192 large part of the research effort in the SimGrid project relates to
193 simulation models. These models are implemented in SURF, and Arnaud has
194 refactored SURF to make it more easily extensible so that one can
195 experiment with different models, in particular different network models.
196 Pedro Velho, who works with Arnaud, is currently experimenting with several
197 new network models. Also, Kayo Fujiwara, who works with Henri, has
198 interfaced SURF with (a patched version of) the GTNetS packet-level
201 The current architecture in the CVS tree at the time this document is
202 being written is as follows:
205 ----------------------------------
208 |SimDag| MSG | GRAS | SMPI | (Note that GRAS and SMPI also run on top of
209 | | | ------- | sockets and MPI, not shown on the figure)
211 | ---------------------------
213 ----------------------------------
215 ----------------------------------
216 | SURF kernel | | GTNetS |
217 | (several models) | | |
218 -------------------- ----------\endverbatim
220 \section history_future Future Directions
222 The primary short-term future direction is to develop a distributed version of
223 SIMiX to increase the scalability of simulations in terms of memory. This can be done
224 using the GRAS "real world" functionality to run SIMiX in a distributed fashion
225 across multiple hosts, thus allowing to run simulations that are not
226 limited by the amount of memory on a single host. The simulation itself
227 would still be centralized and sequential, meaning that a single simulated
228 process would run at a time. Bruno Donassolo is currently working on this
229 idea, which is currently called SMURF.
231 Longer-term plans include:
233 \li More development in AMOK
234 \li Component for simulation visualization
235 \li Model-checking in GRAS
236 \li True parallel simulation
239 One of the constant challenge in this project is its duality: it is a
240 useful tool for scientists (hence our efforts on APIs, portability,
241 documentation, etc.), but is it also a scientific project in its own right
242 (so that we can publish papers).
