ee34be05beb5e02e89c8fd61b407cd516fa06381
[charm.git] / doc / ampi / manual.tex
1 \documentclass[10pt]{article}
2 \usepackage{../pplmanual}
3 \input{../pplmanual}
4
5 \title{Adaptive MPI Manual}
6 \version{1.0}
7 \credits{
8 AMPI has been developed by Milind Bhandarkar with inputs from Gengbin Zheng and
9 Orion Lawlor. The derived data types (DDT) library, which AMPI uses for the
10 derived data types support, has been developed by Neelam Saboo. The current 
11 version of AMPI is maintained by Chao Huang.
12 }
13
14 \begin{document}
15 \maketitle
16
17 \section{Introduction}
18
19 This manual describes Adaptive MPI~(\ampi{}), which is an implementation of a
20 significant subset\footnote{Currently, 110 MPI-1.1 Standard functions have 
21 been implemented.} of MPI-1.1 Standard over \charmpp{}. \charmpp{} is a
22 \CC{}-based parallel programming library being developed by Prof. L. V. Kal\'{e} 
23 and his students back from 1992 until now at University of Illinois.
24
25 We first describe our philosophy behind this work (why we do what we do).
26 Later we give a brief introduction to \charmpp{} and rationale for \ampi{}
27 (tools of the trade). We then describe \ampi{} in detail. Finally we summarize the
28 changes required for original MPI codes to get them working with \ampi{}
29 (current state of our work). Appendices contain the gory details of installing
30 \ampi{}, building and running \ampi{} programs.
31
32 \subsection{Overview}
33
34 Developing parallel Computational Science and Engineering (CSE) applications is
35 a complex task. One has to implement the right physics, develop or choose and
36 code appropriate numerical methods, decide and implement the proper input and
37 output data formats, perform visualizations, and be concerned with correctness
38 and efficiency of the programs. It becomes even more complex for multi-physics
39 coupled simulations such as the solid propellant rocket simulation application. In addition, many applications
40  are dynamic and adaptively refined so load imbalance is a major challenge.
41 Our philosophy is to lessen the burden of the application developers by
42 providing advanced programming paradigms and versatile runtime systems that can
43 handle many common programming and performance concerns automatically and let the application
44 programmers focus on the actual application content.
45
46 Many of these concerns can be addressed using processor virtualization and 
47 over-decomposition philosophy of \charmpp{}. Thus, the developer only sees 
48 virtual processors and lets the runtime system deal with underlying physical 
49 processors. This is implemented in \ampi{} by mapping MPI ranks to \charmpp{} user-level
50  threads as illustrated in Figure\ref{fig_virt}. As an immediate and simple benefit, the programmer can use as 
51 many virtual processors ("MPI ranks") as the problem can be easily decomposed
52  to them. For example, suppose the problem domain has $n*2^n$ parts that can be
53   easily distributed but programming for general number of MPI processes is burdensome, 
54   then the developer can have $n*2^n$ virtual processors on any number of physical ones using \ampi{}.
55   
56 \begin{figure}[h]
57 \centering
58 \includegraphics[width=4.6in]{figs/virtualization.png}
59 \caption{MPI processes are implemented as user-level threads in \ampi{}}
60 \label{fig_virt}
61 \end{figure}
62
63 \ampi{}'s execution model consists of multiple user-level threads per process and,
64 typically, there is one process per physical processor. \charmpp{} scheduler coordinates
65 execution of these threads (also called Virtual Processors or VPs) and controls execution as shown in Figure \ref{fig_ratio}. These
66 VPs can also migrate between processors because of load balancing or other reasons.
67 The number of VPs per processor specifies the virtualization ratio (degree of over-decomposition). For example, in Figure \ref{fig_ratio} virtualization ratio is four (there are four VPs per each processor). Figure \ref{fig_prac} show how the problem domain is over-decomposed in \ampi{}'s VPs as opposed to other MPI implementations.
68
69 \begin{figure}[h]
70 \centering
71 \includegraphics[width=1.8in]{figs/ratio.png}
72 \caption{VPs are managed by \charmpp{} scheduler}
73 \label{fig_ratio}
74 \end{figure}
75
76 \begin{figure}[h]
77 \centering
78 \includegraphics[width=4.6in]{figs/prac.png}
79 \caption{Problem domain is over-decomposed to more VPs}
80 \label{fig_prac}
81 \end{figure}
82
83 Another benefit of virtualization is communication and computation overlap which 
84 is automatically achieved without programming effort. Techniques such as software 
85 pipelining require significant programming 
86 effort to achieve this goal and improve performance. However, one can use \ampi{} to 
87 have more virtual processors than physical processors to overlap communication and 
88 computation. Each time a VP is blocked for communication, \charmpp{} scheduler
89  picks the next VP among those that are ready to execute. In this manner, while
90  some of the VPs of a physical processor are 
91 waiting for a message to arrive, others can continue their execution. Thus, performance 
92 will be improved without any change to the source code.
93
94 A potential benefit is that of better cache utilization. With over-decomposition, a smaller subdomain is accessed by a VP repeatedly in different function calls before getting blocked by communication and switching to another VP. That smaller subdomain may fit into cache if over-decomposition is enough. This concept is illustrated in Figure \ref{fig_cache} where each \ampi{} subdomain (such as 12) is smaller than corresponding MPI subdomain (such as 3) and may fit into cache memory. Thus, there is a potential performance improvement without changing the source code.
95
96 \begin{figure}[h]
97 \centering
98 \includegraphics[width=4.6in]{figs/cache.png}
99 \caption{Smaller subdomains may fit into cache and result in better performance}
100 \label{fig_cache}
101 \end{figure}
102
103 One important concern is that of load imbalance. New generation parallel applications are 
104 dynamically varying, meaning that processors' load is shifting during execution. In a dynamic simulation application
105 such as rocket simulation, burning  solid fuel, sub-scaling for a certain part
106 of the mesh, crack propagation, particle flows all contribute to load
107 imbalance. Centralized load balancing strategy built into an application is
108 impractical since each individual modules are developed almost independently by
109 various developers. In addition, embedding a load balancing strategy in the code 
110 complicates it and programming effort increases significantly. Thus, the runtime 
111 system support for load balancing becomes even more critical. Figure \ref{fig_migrate} shows migration of a VP because of load imbalance. For instance, this domain may correspond to a weather forecast model where there is a tornado in top-left side, which requires more computation to simulate. \ampi{} will then migrate VP 13 to balance the division of work across processors and improve performance. Note that incorporating this sort of load balancing inside the application code may take a lot of effort and complicates the code.
112
113 \begin{figure}[h]
114 \centering
115 \includegraphics[width=4.6in]{figs/migrate.png}
116 \caption{\ampi{} migrates VPs across processors for load balancing}
117 \label{fig_migrate}
118 \end{figure}
119
120 There are different load balancing strategies built into \charmpp{} that can be 
121 selected. Among those, some may fit better for an application depending on its 
122 characteristics. Moreover, one can write a new load balancer, best suited for an 
123 application, by the simple API provided inside \charmpp{} infrastructure. Our approach is
124 based on actual measurement of load information at runtime, and on migrating
125 computations from heavily loaded to lightly loaded processors.
126
127 For this approach to be effective, we need the computation to be split into
128 pieces many more in number than available processors. This allows us to
129 flexibly map and re-map these computational pieces to available processors.
130 This approach is usually called ``multi-domain decomposition''.
131
132 \charmpp{}, which we use as a runtime system layer for the work described here,
133 simplifies our approach. It embeds an elaborate performance tracing mechanism,
134 a suite of plug-in load balancing strategies, infrastructure for defining and
135 migrating computational load, and is interoperable with other programming
136 paradigms.
137
138 \subsection{Terminology}
139
140 \begin{description}
141
142 \item[Module] A module refers to either a complete program or a library with an
143 orchestrator subroutine\footnote{Like many software engineering terms, this
144 term is overused, and unfortunately clashes with Fortran 90 module that denotes
145 a program unit. We specifically refer to the later as ``Fortran 90 module'' to
146 avoid confusion.} . An orchestrator subroutine specifies the main control flow
147 of the module by calling various subroutines from the associated library and
148 does not usually have much state associated with it.
149
150 \item[Thread] A thread is a lightweight process that owns a stack and machine
151 registers including program counter, but shares code and data with other
152 threads within the same address space. If the underlying operating system
153 recognizes a thread, it is known as kernel thread, otherwise it is known as
154 user-thread. A context-switch between threads refers to suspending one thread's
155 execution and transferring control to another thread. Kernel threads typically
156 have higher context switching costs than user-threads because of operating
157 system overheads. The policy implemented by the underlying system for
158 transferring control between threads is known as thread scheduling policy.
159 Scheduling policy for kernel threads is determined by the operating system, and
160 is often more inflexible than user-threads. Scheduling policy is said to be
161 non-preemptive if a context-switch occurs only when the currently running
162 thread willingly asks to be suspended, otherwise it is said to be preemptive.
163 \ampi{} threads are non-preemptive user-level threads.
164
165 \item[Chunk] A chunk is a combination of a user-level thread and the data it
166 manipulates. When a program is converted from MPI to \ampi{}, we convert an MPI
167 process into a chunk. This conversion is referred to as chunkification.
168
169 \item[Object] An object is just a blob of memory on which certain computations
170 can be performed. The memory is referred to as an object's state, and the set
171 of computations that can be performed on the object is called the interface of
172 the object.
173
174 \end{description}
175
176 \section{\charmpp{}}
177
178 \charmpp{} is an object-oriented parallel programming library for \CC{}.  It
179 differs from traditional message passing programming libraries (such as MPI) in
180 that \charmpp{} is ``message-driven''. Message-driven parallel programs do not
181 block the processor waiting for a message to be received.  Instead, each
182 message carries with itself a computation that the processor performs on
183 arrival of that message. The underlying runtime system of \charmpp{} is called
184 \converse{}, which implements a ``scheduler'' that chooses which message to
185 schedule next (message-scheduling in \charmpp{} involves locating the object
186 for which the message is intended, and executing the computation specified in
187 the incoming message on that object). A parallel object in \charmpp{} is a
188 \CC{} object on which a certain computations can be asked to performe from
189 remote processors.
190
191 \charmpp{} programs exhibit latency tolerance since the scheduler always picks
192 up the next available message rather than waiting for a particular messageto
193 arrive.  They also tend to be modular, because of their object-based nature.
194 Most importantly, \charmpp{} programs can be \emph{dynamically load balanced},
195 because the messages are directed at objects and not at processors; thus
196 allowing the runtime system to migrate the objects from heavily loaded
197 processors to lightly loaded processors. It is this feature of \charmpp{} that
198 we utilize for \ampi{}.
199
200 Since many CSE applications are originally written using MPI, one would have to
201 do a complete rewrite if they were to be converted to \charmpp{} to take
202 advantage of dynamic load balancing. This is indeed impractical. However,
203 \converse{} -- the runtime system of \charmpp{} -- came to our rescue here,
204 since it supports interoperability between different parallel programming
205 paradigms such as parallel objects and threads. Using this feature, we
206 developed \ampi{}, an implementation of a significant subset of MPI-1.1
207 standard over \charmpp{}.  \ampi{} is described in the next section.
208
209 \section{AMPI}
210
211 \ampi{} utilizes the dynamic load balancing capabilities of \charmpp{} by
212 associating a ``user-level'' thread with each \charmpp{} migratable object.
213 User's code runs inside this thread, so that it can issue blocking receive
214 calls similar to MPI, and still present the underlying scheduler an opportunity
215 to schedule other computations on the same processor. The runtime system keeps
216 track of computation loads of each thread as well as communication graph
217 between \ampi{} threads, and can migrate these threads in order to balance the
218 overall load while simultaneously minimizing communication overhead. 
219
220 \subsection{AMPI Status}
221
222 Currently all the MPI-1.1 Standard functions are supported in \ampi{}, with a
223 collection of our extentions explained in detail in this manual. One-sided
224 communication calls in MPI-2 are implemented, but they are not taking advantage
225 of RMA features yet. Also ROMIO\footnote{http://www-unix.mcs.anl.gov/romio/} 
226 has been integrated to support parallel I/O features. Link with {\tt -lampiromio}
227 to take advantage of this library.
228
229 Following MPI-1.1 basic datatypes are supported in \ampi{}. (Some are not 
230 available in Fortran binding. Refer to MPI-1.1 Standard for details.)
231 \begin{alltt}
232 MPI_DATATYPE_NULL  MPI_BYTE            MPI_UNSIGNED_LONG MPI_LONG_DOUBLE_INT
233 MPI_DOUBLE         MPI_PACKED          MPI_LONG_DOUBLE   MPI_2FLOAT
234 MPI_INT            MPI_SHORT           MPI_FLOAT_INT     MPI_2DOUBLE
235 MPI_FLOAT          MPI_LONG            MPI_DOUBLE_INT    MPI_LB
236 MPI_COMPLEX        MPI_UNSIGNED_CHAR   MPI_LONG_INT      MPI_UB
237 MPI_LOGICAL        MPI_UNSIGNED_SHORT  MPI_2INT
238 MPI_CHAR           MPI_UNSIGNED        MPI_SHORT_INT
239 \end{alltt}
240
241 Following MPI-1.1 reduction operations are supported in \ampi{}.
242
243 \begin{alltt}
244 MPI_MAX   MPI_MIN   MPI_SUM   MPI_PROD  MPI_MAXLOC  MPI_MINLOC
245 MPI_LAND  MPI_LOR   MPI_LXOR  MPI_BAND  MPI_BOR     MPI_BXOR
246 \end{alltt}
247
248 Following are AMPI extension calls, which will be explained in detail in this
249 manual.
250 \begin{alltt}
251 MPI_Migrate     MPI_Checkpoint  MPI_Restart     MPI_Register    MPI_Get_userdata
252 MPI_Ialltoall   MPI_Iallgather  MPI_Iallreduce  MPI_Ireduce     MPI_IGet
253 \end{alltt}
254
255
256 \subsection{Name for Main Program}
257
258 To convert an existing program to use AMPI, the main function or program may need to be renamed. The changes should be made as follows:
259
260 \subsubsection{Fortran}
261
262 You must declare the main program as a subroutine called ``MPI\_MAIN''. Do not declare the main subroutine as a \textit{program} because it will never be called by the AMPI runtime.
263
264 \subsubsection{C or C++}
265
266 The main function can be left as is, if \texttt{mpi.h} is included before the main function. This header file has a preprocessor macro that renames main, and the renamed version is called by the AMPI runtime by each thread.
267
268
269 \subsection{Global Variable Privatization}
270
271 For dynamic load balancing to be effective, one needs to map multiple
272 user-level threads onto a processor. Traditional MPI programs assume that the
273 entire processor is allocated to themselves, and that only one thread of
274 control exists within the process's address space.  Thats where the need arises
275 to make some transformations to the original MPI program in order to run
276 correctly with \ampi{}.
277
278 The basic transformation needed to port the MPI program to \ampi{} is
279 privatization of global variables.\footnote{Typical Fortran MPI programs
280 contain three types of global variables.
281
282 \begin{enumerate}
283
284 \item Global variables that are ``read-only''. These are either
285 \emph{parameters} that are set at compile-time. Or other variables that are
286 read as input or set at the beginning of the program and do not change during
287 execution. It is not necessary to privatize such variables.
288
289 \item Global variables that are used as temporary buffers. These are variables
290 that are used temporarily to store values to be accessible across subroutines.
291 These variables have a characteristic that there is no blocking call such as
292 \texttt{MPI\_recv} between the time the variable is set and the time it is ever
293 used. It is not necessary to privatize such variables either. 
294
295 \item True global variables. These are used across subroutines that contain
296 blocking receives and therefore possibility of a context switche between the
297 definition and use of the variable. These variables need to be privatized.
298
299 \end{enumerate}
300 }
301 With the MPI process model, each MPI node can keep a copy of its own
302 ``permanent variables'' -- variables that are accessible from more than one
303 subroutines without passing them as arguments.  Module variables, ``saved''
304 subroutine local variables, and common blocks in Fortran 90 belong to this
305 category. If such a program is executed without privatization on \ampi{}, all
306 the \ampi{} threads that reside on one processor will access the same copy of
307 such variables, which is clearly not the desired semantics.  To ensure correct
308 execution of the original source program, it is necessary to make such
309 variables ``private'' to individual threads. We are two choices: automatic 
310 global swapping and manual code modification.
311
312 \subsubsection{Automatic Globals Swapping}
313 Thanks to the ELF Object Format, we have successfully automated the procedure 
314 of switching the set of user global variables when switching thread contexts. 
315 The only thing that the user needs to do is to set flag {\tt -swapglobals} 
316 at compile and link time. Currently this feature only works on x86 and x86\_64
317  (i.e. amd64) platforms that fully support ELF. Thus it will not work on PPC or
318   Itanium, or on some microkernels such as Catamount.When this feature does
319    not work for you,
320 you are advised to make the modification manually, which is detailed in the
321 following section.
322
323 \subsubsection{Manual Change}
324 We have employed a strategy of argument passing to do this privatization
325 transformation. That is, the global variables are bunched together in a
326 single user-defined type, which is allocated by each thread dynamically. Then a
327 pointer to this type is passed from subroutine to subroutine as an argument.
328 Since the subroutine arguments are passed on a stack, which is not shared
329 across all threads, each subroutine, when executing within a thread operates on
330 a private copy of the global variables. 
331
332 This scheme is demonstrated in the following examples. The original Fortran 90 
333 code contains a module \texttt{shareddata}. This module is used in the main 
334 program and a subroutine \texttt{subA}.
335
336 \begin{alltt}
337 !FORTRAN EXAMPLE
338 MODULE shareddata
339   INTEGER :: myrank
340   DOUBLE PRECISION :: xyz(100)
341 END MODULE
342
343 SUBROUTINE MPI_MAIN
344   USE shareddata
345   include 'mpif.h'
346   INTEGER :: i, ierr
347   CALL MPI_Init(ierr)
348   CALL MPI_Comm_rank(MPI_COMM_WORLD, myrank, ierr)
349   DO i = 1, 100
350     xyz(i) =  i + myrank
351   END DO
352   CALL subA
353   CALL MPI_Finalize(ierr)
354 END PROGRAM
355
356 SUBROUTINE subA
357   USE shareddata
358   INTEGER :: i
359   DO i = 1, 100
360     xyz(i) = xyz(i) + 1.0
361   END DO
362 END SUBROUTINE
363
364 //C Example
365 #include <mpi.h>
366
367 int myrank;
368 double xyz[100];
369
370 void subA();
371 int main(int argc, char** argv)\{
372   int i;
373   MPI_Init(&argc, &argv);
374   MPI_Comm_rank(MPI_COMM_WORLD, myrank);
375   for(i=0;i<100;i++)
376     xyz[i] = i + myrank;
377   subA();
378   MPI_Finalize();
379 \}
380
381 void subA()\{
382   int i;
383   for(i=0;i<100;i++)
384     xyz[i] = xyz[i] + 1.0;
385 \}
386 \end{alltt}
387
388 \ampi{} executes the main subroutine inside a user-level thread as a subroutine. 
389  
390 Now we transform this program using the argument passing strategy. We first group the
391 shared data into a user-defined type.
392
393 \begin{alltt}
394 !FORTRAN EXAMPLE
395 MODULE shareddata
396   \emph{TYPE chunk}
397     INTEGER :: myrank
398     DOUBLE PRECISION :: xyz(100)
399   \emph{END TYPE}
400 END MODULE
401
402 //C Example
403 struct shareddata\{
404   int myrank;
405   double xyz[100];
406 \};
407 \end{alltt}
408
409 Now we modify the main subroutine to dynamically allocate this data and change the
410 references to them. Subroutine \texttt{subA} is then modified to take this data
411 as argument. 
412
413 \begin{alltt}
414 !FORTRAN EXAMPLE
415 SUBROUTINE MPI_Main
416   USE shareddata
417   USE AMPI
418   INTEGER :: i, ierr
419   \emph{TYPE(chunk), pointer :: c}
420   CALL MPI_Init(ierr)
421   \emph{ALLOCATE(c)}
422   CALL MPI_Comm_rank(MPI_COMM_WORLD, c\%myrank, ierr)
423   DO i = 1, 100
424     \emph{c\%xyz(i) =  i + c\%myrank}
425   END DO
426   CALL subA(c)
427   CALL MPI_Finalize(ierr)
428 END SUBROUTINE
429
430 SUBROUTINE subA(c)
431   USE shareddata
432   \emph{TYPE(chunk) :: c}
433   INTEGER :: i
434   DO i = 1, 100
435     \emph{c\%xyz(i) = c\%xyz(i) + 1.0}
436   END DO
437 END SUBROUTINE
438
439 //C Example
440 void MPI_Main\{
441   int i,ierr;
442   struct shareddata *c;
443   ierr = MPI_Init();
444   c = (struct shareddata*)malloc(sizeof(struct shareddata));
445   ierr = MPI_Comm_rank(MPI_COMM_WORLD, c.myrank);
446   for(i=0;i<100;i++)
447     c.xyz[i] = i + c.myrank;
448   subA(c);
449   ierr = MPI_Finalize();
450 \}
451
452 void subA(struct shareddata *c)\{
453   int i;
454   for(i=0;i<100;i++)
455     c.xyz[i] = c.xyz[i] + 1.0;
456 \}
457 \end{alltt}
458
459 With these changes, the above program can be made thread-safe. Note that it is
460 not really necessary to dynamically allocate \texttt{chunk}. One could have
461 declared it as a local variable in subroutine \texttt{MPI\_Main}.  (Or for a
462 small example such as this, one could have just removed the \texttt{shareddata}
463 module, and instead declared both variables \texttt{xyz} and \texttt{myrank} as
464 local variables). This is indeed a good idea if shared data are small in size.
465 For large shared data, it would be better to do heap allocation because in
466 \ampi{}, the stack sizes are fixed at the beginning (can be specified from the
467 command line) and stacks do not grow dynamically.
468
469
470
471 \subsection{Extensions for Migrations}
472
473 For MPI chunks to migrate, we have added a few calls to \ampi{}. These include
474 ability to register thread-specific data with the run-time system, to pack all
475 the thread's data, and to express willingness to migrate.
476
477 \subsubsection{Registering Chunk data}
478
479 When the \ampi{} runtime system decides that load imbalance exists within the
480 application, it will invoke one of its internal load balancing strategies,
481 which determines the new mapping of \ampi{} chunks so as to balance the load.
482 Then \ampi{} runtime has to pack up the chunk's state and move it to its new
483 home processor. \ampi{} packs up any internal data in use by the chunk,
484 including the thread's stack in use. This means that the local variables
485 declared in subroutines in a chunk, which are created on stack, are
486 automatically packed up by the \ampi{} runtime system. However, it has no way
487 of knowing what other data are in use by the chunk. Thus upon starting
488 execution, a chunk needs to notify the system about the data that it is going
489 to use (apart from local variables.) Even with the data registration, \ampi{}
490 cannot determine what size the data is, or whether the registered data contains
491 pointers to other places in memory. For this purpose, a packing subroutine also
492 needs to be provided to the \ampi{} runtime system along with registered data.
493 (See next section for writing packing subroutines.) The call provided by
494 \ampi{} for doing this is \texttt{MPI\_Register}. This function takes two
495 arguments: A data item to be transported alongwith the chunk, and the pack
496 subroutine, and returns an integer denoting the registration identifier. In
497 C/\CC{} programs, it may be necessary to use this return value after migration
498 completes and control returns to the chunk, using function
499 \texttt{MPI\_Get\_userdata}. Therefore, the return value should be stored in a
500 local variable.
501
502 \subsubsection{Migration}
503
504 The \ampi{} runtime system could detect load imbalance by itself and invoke the
505 load balancing strategy. However, since the application code is going to
506 pack/unpack the chunk's data, writing the pack subroutine will be complicated
507 if migrations occur at a stage unknown to the application. For example, if the
508 system decides to migrate a chunk while it is in initialization stage (say,
509 reading input files), application code will have to keep track of how much data
510 it has read, what files are open etc. Typically, since initialization occurs
511 only once in the beginning, load imbalance at that stage would not matter much.
512 Therefore, we want the demand to perform load balance check to be initiated by
513 the application.
514
515 \ampi{} provides a subroutine \texttt{MPI\_Migrate} for this purpose. Each
516 chunk periodically calls \texttt{MPI\_Migrate}. Typical CSE applications are
517 iterative and perform multiple time-steps. One should call
518 \texttt{MPI\_Migrate} in each chunk at the end of some fixed number of
519 timesteps. The frequency of \texttt{MPI\_Migrate} should be determined by a
520 tradeoff between conflicting factors such as the load balancing overhead, and
521 performance degradation caused by load imbalance. In some other applications,
522 where application suspects that load imbalance may have occurred, as in the
523 case of adaptive mesh refinement; it would be more effective if it performs a
524 couple of timesteps before telling the system to re-map chunks. This will give
525 the \ampi{} runtime system some time to collect the new load and communication
526 statistics upon which it bases its migration decisions. Note that
527 \texttt{MPI\_Migrate} does NOT tell the system to migrate the chunk, but
528 merely tells the system to check the load balance after all the chunks call
529 \texttt{MPI\_Migrate}. To migrate the chunk or not is decided only by the
530 system's load balancing strategy.
531
532 \subsubsection{Packing/Unpacking Thread Data}
533
534 Once the \ampi{} runtime system decides which chunks to send to which
535 processors, it calls the specified pack subroutine for that chunk, with the
536 chunk-specific data that was registered with the system using
537 \texttt{MPI\_Register}. This section explains how a subroutine should be
538 written for performing pack/unpack.
539
540 There are three steps to transporting the chunk's data to other processor.
541 First, the system calls a subroutine to get the size of the buffer required to
542 pack the chunk's data. This is called the ``sizing'' step. In the next step,
543 which is called immediately afterward on the source processor, the system
544 allocates the required buffer and calls the subroutine to pack the chunk's data
545 into that buffer. This is called the ``packing'' step. This packed data is then
546 sent as a message to the destination processor, where first a chunk is created
547 (alongwith the thread) and a subroutine is called to unpack the chunk's data
548 from the buffer. This is called the ``unpacking'' step.
549
550 Though the above description mentions three subroutines called by the \ampi{}
551 runtime system, it is possible to actually write a single subroutine that will
552 perform all the three tasks. This is achieved using something we call a
553 ``pupper''. A pupper is an external subroutine that is passed to the chunk's
554 pack-unpack-sizing subroutine, and this subroutine, when called in different
555 phases performs different tasks. An example will make this clear:
556
557 Suppose the chunk data is defined as a user-defined type in Fortran 90:
558
559 \begin{alltt}
560 !FORTRAN EXAMPLE
561 MODULE chunkmod
562   TYPE, PUBLIC :: chunk
563       INTEGER , parameter :: nx=4, ny=4, tchunks=16
564       REAL(KIND=8) t(22,22)
565       INTEGER xidx, yidx
566       REAL(KIND=8), dimension(400):: bxm, bxp, bym, byp
567   END TYPE chunk
568 END MODULE
569
570 //C Example
571 struct chunk\{
572   double t;
573   int xidx, yidx;
574   double bxm,bxp,bym,byp;
575 \};
576 \end{alltt}
577
578 Then the pack-unpack subroutine \texttt{chunkpup} for this chunk module is
579 written as:
580
581 \begin{alltt}
582 !FORTRAN EXAMPLE
583 SUBROUTINE chunkpup(p, c)
584   USE pupmod
585   USE chunkmod
586   IMPLICIT NONE
587   INTEGER :: p
588   TYPE(chunk) :: c
589
590   call pup(p, c\%t)
591   call pup(p, c\%xidx)
592   call pup(p, c\%yidx)
593   call pup(p, c\%bxm)
594   call pup(p, c\%bxp)
595   call pup(p, c\%bym)
596   call pup(p, c\%byp)
597 end subroutine
598
599 //C Example
600 void chunkpup(pup_er p, struct chunk c)\{
601   pup_double(p,c.t);
602   pup_int(p,c.xidx);
603   pup_int(p,c.yidx);
604   pup_double(p,c.bxm);
605   pup_double(p,c.bxp);
606   pup_double(p,c.bym);
607   pup_double(p,c.byp);
608 \}
609 \end{alltt}
610
611 There are several things to note in this example. First, the same subroutine
612 \texttt{pup} (declared in module \texttt{pupmod}) is called to size/pack/unpack
613 any type of data. This is possible because of procedure overloading possible in
614 Fortran 90. Second is the integer argument \texttt{p}. It is this argument that
615 specifies whether this invocation of subroutine \texttt{chunkpup} is sizing,
616 packing or unpacking. Third, the integer parameters declared in the type
617 \texttt{chunk} need not be packed or unpacked since they are guaranteed to be
618 constants and thus available on any processor.
619
620 A few other functions are provided in module \texttt{pupmod}. These functions
621 provide more control over the packing/unpacking process. Suppose one modifies
622 the \texttt{chunk} type to include allocatable data or pointers that are
623 allocated dynamically at runtime. In this case, when the chunk is packed, these
624 allocated data structures should be deallocated after copying them to buffers,
625 and when the chunk is unpacked, these data structures should be allocated
626 before copying them from the buffers.  For this purpose, one needs to know
627 whether the invocation of \texttt{chunkpup} is a packing one or unpacking one.
628 For this purpose, the \texttt{pupmod} module provides functions
629 \verb+fpup_isdeleting+(\verb+fpup_isunpacking+). These functions return logical value
630 \verb+.TRUE.+ if the invocation is for packing (unpacking), and \verb+.FALSE.+
631 otherwise. Following example demonstrates this:
632
633 Suppose the type \texttt{dchunk} is declared as:
634
635 \begin{alltt}
636 !FORTRAN EXAMPLE
637 MODULE dchunkmod
638   TYPE, PUBLIC :: dchunk
639       INTEGER :: asize
640       REAL(KIND=8), pointer :: xarr(:), yarr(:)
641   END TYPE dchunk
642 END MODULE
643
644 //C Example
645 struct dchunk\{
646   int asize;
647   double* xarr, *yarr;
648 \};
649 \end{alltt}
650
651 Then the pack-unpack subroutine is written as:
652
653 \begin{alltt}
654 !FORTRAN EXAMPLE
655 SUBROUTINE dchunkpup(p, c)
656   USE pupmod
657   USE dchunkmod
658   IMPLICIT NONE
659   INTEGER :: p
660   TYPE(dchunk) :: c
661
662   pup(p, c\%asize)
663   \emph{
664   IF (fpup_isunpacking(p)) THEN       !! if invocation is for unpacking
665     allocate(c\%xarr(asize))
666     ALLOCATE(c\%yarr(asize))
667   ENDIF
668   }
669   pup(p, c\%xarr)
670   pup(p, c\%yarr)
671   \emph{
672   IF (fpup_isdeleting(p)) THEN        !! if invocation is for packing
673     DEALLOCATE(c\%xarr(asize))
674     DEALLOCATE(c\%yarr(asize))
675   ENDIF
676   }
677
678 END SUBROUTINE
679
680 //C Example
681 void dchunkpup(pup_er p, struct dchunk c)\{
682   pup_int(p,c.asize);
683   if(pup_isUnpacking(p))\{
684     c.xarr = (double *)malloc(sizeof(double)*c.asize);
685     c.yarr = (double *)malloc(sizeof(double)*c.asize);
686   \}
687   pup_doubles(p,c.xarr,c.asize);
688   pup_doubles(p,c.yarr,c.asize);
689   if(pup_isPacking(p))\{
690     free(c.xarr);
691     free(c.yarr);
692   \}
693 \}
694 \end{alltt}
695
696 One more function \verb+fpup_issizing+ is also available in module \texttt{pupmod}
697 that returns \verb+.TRUE.+ when the invocation is a sizing one. In practice one
698 almost never needs to use it.
699
700 \subsection{Extensions for Checkpointing}
701
702 The pack-unpack subroutines written for migrations make sure that the current
703 state of the program is correctly packed (serialized) so that it can be
704 restarted on a different processor. Using the \emph{same} subroutines, it
705 is also possible to save the state of the program to disk, so that if the 
706 program were to crash abruptly, or if the allocated time for the program
707 expires before completing execution, the program can be restarted from the
708 previously checkpointed state. Thus, the pack-unpack subroutines act as the 
709 key facility for checkpointing in addition to their usual role for migration.
710
711 A subroutine for checkpoint purpose has been added to AMPI:
712 \texttt{void MPI\_Checkpoint(char *dirname);}
713 This subroutine takes a directory name as its argument. It is a collective 
714 function, meaning every virtual processor in the program needs to call this 
715 subroutine and specify the same directory name. (Typically, in an
716 iterative AMPI program, the iteration number, converted to a character string,
717 can serve as a checkpoint directory name.) This directory is created, and the
718 entire state of the program is checkpointed to this directory.  One can restart
719 the program from the checkpointed state by specifying \texttt{"+restart
720 dirname"} on the command-line. This capability is powered by the \charmpp{} 
721 runtime system. For more information about \charmpp{} checkpoint/restart
722 mechanism please refer to \charmpp{} manual. 
723
724 \subsection{Extensions for Memory Efficiency}
725
726 MPI functions usually require the user to preallocate the data buffers needed before the
727 functions being called. For unblocking communication primitives, sometimes the user would
728 like to do lazy memory allocation until the data actually arrives, which gives the
729 oppotunities to write more memory efficient programs.     
730 We provide a set of AMPI functions as an extension to the standard MPI-2 one-sided calls,
731 where we provide a split phase MPI\_Get called MPI\_IGet. MPI\_IGet preserves the similar
732 semantics as MPI\_Get except that no user buffer is provided to hold incoming data.
733 MPI\_IGet\_Wait will block until the requested data arrives and runtime system takes
734 care to allocate space, do appropriate unpacking based on data type, and return.
735 MPI\_IGet\_Free lets the runtime system free the resources being used for this get request
736 including the data buffer. And MPI\_IGet\_Data is the utility program that returns the
737 actual data.     
738  
739
740 \begin{alltt}
741
742 int MPI_IGet(MPI_Aint orgdisp, int orgcnt, MPI_Datatype orgtype, int rank,
743              MPI_Aint targdisp, int targcnt, MPI_Datatype targtype, MPI_Win win,
744              MPI_Request *request);
745
746 int MPI_IGet_Wait(MPI_Request *request, MPI_Status *status, MPI_Win win);
747
748 int MPI_IGet_Free(MPI_Request *request, MPI_Status *status, MPI_Win win);
749
750 char* MPI_IGet_Data(MPI_Status status);
751
752 \end{alltt}
753
754
755
756 \subsection{Extensions for Interoperability}
757
758 Interoperability between different modules is essential for coding coupled
759 simulations.  In this extension to \ampi{}, each MPI application module runs
760 within its own group of user-level threads distributed over the physical
761 parallel machine.  In order to let \ampi{} know which chunks are to be created,
762 and in what order, a top level registration routine needs to be written. A
763 real-world example will make this clear. We have an MPI code for fluids and
764 another MPI code for solids, both with their main programs, then we first
765 transform each individual code to run correctly under \ampi{} as standalone
766 codes. This involves the usual ``chunkification'' transformation so that
767 multiple chunks from the application can run on the same processor without
768 overwriting each other's data. This also involves making the main program into
769 a subroutine and naming it \texttt{MPI\_Main}.
770
771 Thus now, we have two \texttt{MPI\_Main}s, one for the fluids code and one for
772 the solids code. We now make these codes co-exist within the same executable,
773 by first renaming these \texttt{MPI\_Main}s as \texttt{Fluids\_Main} and
774 \texttt{Solids\_Main}\footnote{Currently, we assume that the interface code,
775 which does mapping and interpolation among the boundary values of Fluids and
776 Solids domain, is integrated with one of Fluids and Solids.} writing a
777 subroutine called \texttt{MPI\_Setup}.
778
779 \begin{alltt}
780 !FORTRAN EXAMPLE
781 SUBROUTINE MPI_Setup
782   USE ampi
783   CALL MPI_Register_main(Solids_Main)
784   CALL MPI_Register_main(Fluids_Main)
785 END SUBROUTINE
786
787 //C Example
788 void MPI_Setup()\{
789   MPI_Register_main(Solids_Main);
790   MPI_Register_main(Fluids_Main);
791 \}
792 \end{alltt}
793
794 This subroutine is called from the internal initialization routines of \ampi{}
795 and tells \ampi{} how many number of distinct chunk types (modules) exist, and
796 which orchestrator subroutines they execute.
797
798 The number of chunks to create for each chunk type is specified on the command
799 line when an \ampi{} program is run. Appendix B explains how \ampi{} programs
800 are run, and how to specify the number of chunks (\verb|+vp| option). In the
801 above case, suppose one wants to create 128 chunks of Solids and 64 chunks of
802 Fluids on 32 physical processors, one would specify those with multiple
803 \verb|+vp| options on the command line as:
804
805 \begin{alltt}
806 > charmrun gen1.x +p 32 +vp 128 +vp 64
807 \end{alltt}
808
809 This will ensure that multiple chunk types representing different complete
810 applications can co-exist within the same executable. They can also continue to
811 communicate among their own chunk-types using the same \ampi{} function calls
812 to send and receive with communicator argument as \texttt{MPI\_COMM\_WORLD}.
813 But this would be completely useless if these individual applications cannot
814 communicate with each other, which is essential for building efficient coupled
815 codes.  For this purpose, we have extended the \ampi{} functionality to allow
816 multiple ``\texttt{COMM\_WORLD}s''; one for each application. These \emph{world
817 communicators} form a ``communicator universe'': an array of communicators
818 aptly called \emph{MPI\_COMM\_UNIVERSE}. This array of communicators is 
819 indexed [1 . . . \texttt{MPI\_MAX\_COMM}]. In the current implementation,
820 \texttt{MPI\_MAX\_COMM} is 8, that is, maximum of 8 applications can co-exist
821 within the same executable.
822
823 The order of these \texttt{COMM\_WORLD}s within \texttt{MPI\_COMM\_UNIVERSE}
824 is determined by the order in which individual applications are registered in
825 \texttt{MPI\_Setup}.
826
827 Thus, in the above example, the communicator for the Solids module would be
828 \texttt{MPI\_COMM\_UNIVERSE(1)} and communicator for Fluids module would be
829 \texttt{MPI\_COMM\_UNIVERSE(2)}.
830
831 Now any chunk within one application can communicate with any chunk in the
832 other application using the familiar send or receive \ampi{} calls by
833 specifying the appropriate communicator and the chunk number within that
834 communicator in the call. For example if a Solids chunk number 36 wants to send
835 data to chunk number 47 within the Fluids module, it calls:
836
837 \begin{alltt}
838 !FORTRAN EXAMPLE
839 INTEGER , PARAMETER :: Fluids_Comm = 2
840 CALL MPI_Send(InitialTime, 1, MPI_Double_Precision, tag, 
841               \emph{47, MPI_Comm_Universe(Fluids_Comm)}, ierr)
842
843 //C Example
844 int Fluids_Comm = 2;
845 ierr = MPI_Send(InitialTime, 1, MPI_DOUBLE, tag,
846                 \emph{47, MPI_Comm_Universe(Fluids_Comm)});
847 \end{alltt}
848
849 The Fluids chunk has to issue a corresponding receive call to receive this
850 data:
851
852 \begin{alltt}
853 !FORTRAN EXAMPLE
854 INTEGER , PARAMETER :: Solids_Comm = 1
855 CALL MPI_Recv(InitialTime, 1, MPI_Double_Precision, tag, 
856               \emph{36, MPI_Comm_Universe(Solids_Comm)}, stat, ierr)
857
858 //C Example
859 int Solids_Comm = 1;
860 ierr = MPI_Recv(InitialTime, 1, MPI_DOUBLE, tag,
861                 \emph{36, MPI_Comm_Universe(Solids_Comm)}, &stat);
862 \end{alltt}
863
864 \subsection{Extensions for Sequential Re-run of a Parallel Node}
865 In some scenarios, a sequential re-run of a parallel node is desired. One
866 example is instruction-level accurate architecture simulations, in which case
867 the user may wish to repeat the execution of a node in a parallel run in the
868 sequential simulator. AMPI provides support for such needs by logging the change
869 in the MPI environment on a certain processors. To activate the feature, build 
870 AMPI module with variable ``AMPIMSGLOG'' defined, like the following command in
871 charm directory. (Linking with zlib ``-lz'' might be required with this, for
872 generating compressed log file.)
873
874 \begin{alltt}
875 > ./build AMPI net-linux -DAMPIMSGLOG
876 \end{alltt}
877
878 The feature is used in two phases: writing (logging) the environment and
879 repeating the run. The first logging phase is invoked by a parallel run of the
880 AMPI program with some additional command line options. 
881
882 \begin{alltt}
883 > ./charmrun ./pgm +p4 +vp4 +msgLogWrite +msgLogRank 2 +msgLogFilename "msg2.log"
884 \end{alltt}
885
886 In the above example, a parallel run with 4 processors and 4 VPs will be
887 executed, and the changes in the MPI environment of processor 2 (also VP 2,
888 starting from 0) will get logged into diskfile "msg2.log". 
889
890 Unlike the first run, the re-run is a sequential program, so it is not invoked
891 by charmrun (and omitting charmrun options like +p4 and +vp4), and additional
892 comamnd line options are required as well. 
893
894 \begin{alltt}
895 > ./pgm +msgLogRead +msgLogRank 2 +msgLogFilename "msg2.log"
896 \end{alltt}
897
898 \subsection{Communication Optimizations for AMPI}
899 AMPI is powered by the \charmpp{} communication optimization support now!
900 Currently the user needs to specify the communication pattern by command
901 line option. In the future this can be done automatically by the system.
902
903 Currently there are four strategies available: USE\_DIRECT, USE\_MESH,
904 USE\_HYPERCUBE and USE\_GRID. USE\_DIRECT sends the message directly. 
905 USE\_MESH imposes a 2d Mesh virtual topology on the processors so each 
906 processor sends messages to its neighbors in its row and column of the 
907 mesh which forward the messages to their correct destinations. USE\_HYPERCUBE 
908 and USE\_GRID impose a hypercube and a 3d Grid topologies on the processors. 
909 USE\_HYPERCUBE will do best for very small messages and small number of 
910 processors, 3d has better performance for slightly higher message sizes 
911 and then Mesh starts performing best. The programmer is encouraged to try 
912 out all the strategies. (Stolen from the CommLib manual by Sameer :)
913
914 For more details please refer to the CommLib paper \footnote{L. V. Kale and 
915 Sameer Kumar and Krishnan Vardarajan, 2002. 
916 http://finesse.cs.uiuc.edu/papers/CommLib.pdf}. 
917
918 Specifying the strategy is as simple as a command line option +strategy. For
919 example:
920 \begin{alltt}
921 > ./charmrun +p64 alltoall +vp64 1000 100 +strategy USE\_MESH
922 \end{alltt}
923 tells the system to use MESH strategy for CommLib. By default USE\_DIRECT is
924 used.
925
926 \subsection{User Defined Initial Mapping}
927                                                                                 
928 You can define the initial mapping of virtual processors (vp) to physical 
929 processors (p) as a runtime option. You can choose from predefined initial 
930 mappings or define your own mappings. Following predefined mappings are 
931 available:
932                                                                                 
933 \begin{description}
934
935 \item[Round Robin]
936                                                                                 
937 This mapping scheme, maps virtual processor to physical processor in round-robin
938 fashion, i.e. if there are 8 virtual processors and 2 physical processors then
939 virtual processors indexed 0,2,4,6 will be mapped to physical processor 0 and 
940 virtual processors indexed 1,3,5,7 will be mapped to physical processor 1. 
941
942 \begin{alltt}
943 > ./charmrun ./hello +p2 +vp8 +mapping RR\_MAP
944 \end{alltt}
945                                                                                 
946 \item[Block Mapping]
947                                                                                 
948 This mapping scheme, maps virtual processors to physical processor in chunks, 
949 i.e. if there are 8 virtual processors and 2 physical processors then virtual 
950 processors indexed 0,1,2,3 will be mapped to physical processor 0 and virtual 
951 processors indexed 4,5,6,7 will be mapped to physical processor 1.
952                                                                                 
953 \begin{alltt}
954 > ./charmrun ./hello +p2 +vp8 +mapping BLOCK\_MAP
955 \end{alltt}
956                                                                                 
957 \item[Proportional Mapping]
958                                                                                 
959 This scheme takes the processing capability of physical processors into account
960 for mapping virtual processors to physical processors, i.e. if there are 2 
961 processors with different processing power, then number of virtual processors 
962 mapped to processors will be in proportion to their processing power.
963                                                                                 
964 \begin{alltt}
965 > ./charmrun ./hello +p2 +vp8 +mapping PROP\_MAP
966 > ./charmrun ./hello +p2 +vp8
967 \end{alltt}
968
969 \end{description}
970
971 If you want to define your own mapping scheme, please contact us for help.
972
973 \subsection{Compiling AMPI Programs}
974
975 \charmpp{} provides a cross-platform compile-and-link script called \charmc{}
976 to compile C, \CC{}, Fortran, \charmpp{} and \ampi{} programs.  This script
977 resides in the \texttt{bin} subdirectory in the \charmpp{} installation
978 directory. The main purpose of this script is to deal with the differences of
979 various compiler names and command-line options across various machines on
980 which \charmpp{} runs. While, \charmc{} handles C and \CC{} compiler
981 differences most of the time, the support for Fortran 90 is new, and may have
982 bugs. But \charmpp{} developers are aware of this problem and are working to
983 fix them. Even in its alpha stage of Fortran 90 support, \charmc{} still
984 handles many of the compiler differences across many machines, and it is
985 recommended that \charmc{} be used to compile and linking \ampi{} programs. One
986 major advantage of using \charmc{} is that one does not have to specify which
987 libraries are to be linked for ensuring that \CC{} and Fortran 90 codes are
988 linked correctly together. Appropriate libraries required for linking such
989 modules together are known to \charmc{} for various machines.
990
991 In spite of the platform-neutral syntax of \charmc{}, one may have to specify
992 some platform-specific options for compiling and building \ampi{} codes.
993 Fortunately, if \charmc{} does not recognize any particular options on its
994 command line, it promptly passes it to all the individual compilers and linkers
995 it invokes to compile the program.
996
997 \appendix
998
999 \section{Installing AMPI}
1000
1001 \ampi{} is included in the source distribution of \charmpp{}. 
1002 To get the latest sources from PPL, visit:
1003         http://charm.cs.uiuc.edu/
1004
1005 and follow the download link.
1006 Now one has to build \charmpp{} and \ampi{} from source.
1007
1008 The build script for \charmpp{} is called \texttt{build}. The syntax for this
1009 script is:
1010
1011 \begin{alltt}
1012 > build <target> <version> <opts>
1013 \end{alltt}
1014
1015 For building \ampi{} (which also includes building \charmpp{} and other
1016 libraries needed by \ampi{}), specify \verb+<target>+ to be \verb+AMPI+. And
1017 \verb+<opts>+ are command line options passed to the \verb+charmc+ compile
1018 script.  Common compile time options such as \texttt{-g, -O, -Ipath, -Lpath,
1019 -llib} are accepted. 
1020
1021 To build a debugging version of \ampi{}, use the option: ``\texttt{-g}''. 
1022 To build a production version of \ampi{}, use the options: ``\texttt{-O 
1023 -DCMK\_OPTIMIZE=1}''.
1024
1025 \verb+<version>+ depends on the machine, operating system, and the underlying
1026 communication library one wants to use for running \ampi{} programs.
1027 See the charm/README file for details on picking the proper version.
1028 Following is an example of how to build AMPI under linux and ethernet
1029 environment, with debugging info produced:
1030
1031 \begin{alltt}
1032 > build AMPI net-linux -g
1033 \end{alltt}
1034
1035 \section{Building and Running AMPI Programs}
1036 \subsection{Building}
1037 \charmpp{} provides a compiler called charmc in your charm/bin/ directory. 
1038 You can use this compiler to build your AMPI program the same way as other
1039 compilers like cc. Especially, to build an AMPI program, a command line 
1040 option \emph{-language ampi} should be applied. All the command line 
1041 flags that you would use for other compilers can be used with charmc the 
1042 same way. For example:
1043
1044 \begin{alltt}
1045 > charmc -language ampi -c pgm.c -O3
1046 > charmc -language ampi -o pgm pgm.o -lm -O3 
1047 \end{alltt}
1048
1049 Shortcuts to the AMPI compiler are provided. If you have added charm/bin 
1050 into your \$PATH environment variable, simply type \emph{mpicc, mpiCC, 
1051 mpif77,} and \emph{mpif90} as provided by other MPI implementations.
1052
1053 \begin{alltt}
1054 > mpicc -c pgm.c -g
1055 \end{alltt}
1056
1057 \subsection{Running}
1058 \charmpp{} distribution contains a script called \texttt{charmrun} that makes
1059 the job of running \ampi{} programs portable and easier across all parallel
1060 machines supported by \charmpp{}. \texttt{charmrun} is copied to a directory
1061 where an \ampi{} prgram is built using \charmc{}. It takes a command line
1062 parameter specifying number of processors, and the name of the program followed
1063 by \ampi{} options (such as number of chunks to create, and the stack size of
1064 every chunk) and the program arguments. A typical invocation of \ampi{} program
1065 \texttt{pgm} with \texttt{charmrun} is:
1066
1067 \begin{alltt}
1068 > charmrun pgm +p16 +vp32 +tcharm_stacksize 3276800
1069 \end{alltt}
1070
1071 Here, the \ampi{} program \texttt{pgm} is run on 16 physical processors with
1072 32 chunks (which will be mapped 2 per processor initially), where each
1073 user-level thread associated with a chunk has the stack size of 3,276,800 bytes.
1074
1075 \end{document}