add execution model and history

Author: matthiasdiener

content/execmodel.html

@@ -5,3 +5,98 @@
 <h1>Execution Model</h1>
 
 
+A basic unit of parallel computation in Charm++ programs is a chare. A chare
+is similar to a process, an actor, an ADA task, etc. At its most basic level,
+it is just a C++ object. A Charm++ computation consists of a large number of
+chares distributed on available processors of the system, and interacting with
+each other via asynchronous method invocations. Asynchronously invoking a
+method on a remote object can also be thought of as sending a “message” to it.
+So, these method invocations are sometimes referred to as messages. (besides,
+in the implementation, the method invocations are packaged as messages
+anyway). Chares can be created dynamically.
+
+Conceptually, the system maintains a “work-pool” consisting of seeds for new
+chares, and messages for existing chares. The Charm++ runtime system ( Charm
+RTS) may pick multiple items, non-deterministically, from this pool and
+execute them, with the proviso that two different methods cannot be
+simultaneously executing on the same chare object (say, on different
+processors). Although one can define a reasonable theoretical operational
+semantics of Charm++ in this fashion, a more practical description of
+execution is useful to understand Charm++. A Charm++ application’s execution
+is distributed among Processing Elements (PEs), which are OS threads or
+processes depending on the selected Charm++ build options. On each PE, there
+is a scheduler operating with its own private pool of messages. Each
+instantiated chare has one PE which is where it currently resides. The pool on
+each PE includes messages meant for Chares residing on that PE, and seeds for
+new Chares that are tentatively meant to be instantiated on that PE. The
+scheduler picks a message, creates a new chare if the message is a seed (i.e.
+a constructor invocation) for a new Chare, and invokes the method specified by
+the message. When the method returns control back to the scheduler, it repeats
+the cycle. I.e. there is no pre-emptive scheduling of other invocations.
+
+When a chare method executes, it may create method invocations for other
+chares. The Charm Runtime System (RTS, sometimes referred to as the Chare
+Kernel in the manual) locates the PE where the targeted chare resides, and
+delivers the invocation to the scheduler on that PE.
+
+Methods of a chare that can be remotely invoked are called entry methods.
+Entry methods may take serializable parameters, or a pointer to a message
+object. Since chares can be created on remote processors, obviously some
+constructor of a chare needs to be an entry method. Ordinary entry methods [1]
+are completely non-preemptive- Charm++ will not interrupt an executing method
+to start any other work, and all calls made are asynchronous.
+
+Charm++ provides dynamic seed-based load balancing. Thus location (processor
+number) need not be specified while creating a remote chare. The Charm RTS
+will then place the remote chare on a suitable processor. Thus one can imagine
+chare creation as generating only a seed for the new chare, which may take
+root on some specific processor at a later time.
+
+Chares can be grouped into collections. The types of collections of chares
+supported in Charm++ are: chare-arrays, chare-groups, and chare-nodegroups,
+referred to as arrays, groups, and nodegroups throughout this manual for
+brevity. A Chare-array is a collection of an arbitrary number of migratable
+chares, indexed by some index type, and mapped to processors according to a
+user-defined map group. A group (nodegroup) is a collection of chares, with
+exactly one member element on each PE (“node”).
+
+Charm++ does not allow global variables, except readonly variables. A chare
+can normally only access its own data directly. However, each chare is
+accessible by a globally valid name. So, one can think of Charm++ as
+supporting a global object space.
+
+Every Charm++ program must have at least one mainchare. Each mainchare is
+created by the system on processor 0 when the Charm++ program starts up.
+Execution of a Charm++ program begins with the Charm Kernel constructing all
+the designated mainchares. For a mainchare named X, execution starts at
+constructor X() or X(CkArgMsg *) which are equivalent. Typically, the
+mainchare constructor starts the computation by creating arrays, other chares,
+and groups. It can also be used to initialize shared readonly objects.
+
+Charm++ program execution is terminated by the CkExit call. Like the exit
+system call, CkExit never returns, and it optionally accepts an integer value
+to specify the exit code that is returned to the calling shell. If no exit
+code is specified, a value of zero (indicating successful execution) is
+returned. The Charm RTS ensures that no more messages are processed and no
+entry methods are called after a CkExit. CkExit need not be called on all
+processors; it is enough to call it from just one processor at the end of the
+computation.
+
+As described so far, the execution of individual Chares is “reactive”: When
+method A is invoked the chare executes this code, and so on. But very often,
+chares have specific life-cycles, and the sequence of entry methods they
+execute can be specified in a structured manner, while allowing for some
+localized non-determinism (e.g. a pair of methods may execute in any order,
+but when they both finish, the execution continues in a pre-determined manner,
+say executing a 3rd entry method). To simplify expression of such control
+structures, Charm++ provides two methods: the structured dagger notation,
+which is the main notation we recommend you use. Alternatively, you may use
+threaded entry methods, in combination with futures and sync methods. The
+threaded methods run in light-weight user-level threads, and can block waiting
+for data in a variety of ways. Again, only the particular thread of a
+particular chare is blocked, while the PE continues executing other chares.
+
+The normal entry methods, being asynchronous, are not allowed to return any
+value, and are declared with a void return type. However, the sync methods are
+an exception to this. They must be called from a threaded method, and so are
+allowed to return (certain types of) values.

content/history.html

@@ -4,3 +4,36 @@
 
 <h1>History</h1>
 
+The Charm software was developed as a group effort of the Parallel Programming
+Laboratory at the University of Illinois at Urbana-Champaign. Researchers at
+the Parallel Programming Laboratory keep Charm++ updated for the new machines,
+new programming paradigms, and for supporting and simplifying development of
+emerging applications for parallel processing. The earliest prototype, Chare
+Kernel(1.0), was developed in the late eighties. It consisted only of basic
+remote method invocation constructs available as a library. The second
+prototype, Chare Kernel(2.0), a complete re-write with major design changes.
+This included C language extensions to denote Chares, messages and
+asynchronous remote method invocation. Charm(3.0) improved on this syntax, and
+contained important features such as information sharing abstractions, and
+chare groups (called Branch Office Chares). Charm(4.0) included Charm++ and
+was released in fall 1993. Charm++ in its initial version consisted of
+syntactic changes to C++ and employed a special translator that parsed the
+entire C++ code while translating the syntactic extensions. Charm(4.5) had a
+major change that resulted from a significant shift in the research agenda of
+the Parallel Programming Laboratory. The message-driven runtime system code of
+the Charm++ was separated from the actual language implementation, resulting
+in an interoperable parallel runtime system called Converse. The Charm++
+runtime system was retargetted on top of Converse, and popular programming
+paradigms such as MPI and PVM were also implemented on Converse. This allowed
+interoperability between these paradigms and Charm++. This release also
+eliminated the full-fledged Charm++ translator by replacing syntactic
+extensions to C++ with C++ macros, and instead contained a small language and
+a translator for describing the interfaces of Charm++ entities to the runtime
+system. This version of Charm++, which, in earlier releases was known as
+Interface Translator Charm++, is the default version of Charm++ now, and hence
+referred simply as Charm++. In early 1999, the runtime system of Charm++ was
+rewritten in C++. Several new features were added. The interface language
+underwent significant changes, and the macros that replaced the syntactic
+extensions in original Charm++, were replaced by natural C++ constructs. Late
+1999, and early 2000 reflected several additions to Charm++, when a load
+balancing framework and migratable objects were added to Charm++.