... here1
For a description of the underlying design philosophy please refer to the following papers :
L. V. Kale and Sanjeev Krishnan, ``CHARM++: Parallel Programming with Message-Driven Objects'', in ``Parallel Programming Using C++'', MIT Press, 1995.
L. V. Kale and Sanjeev Krishnan, ``CHARM++: A Portable Concurrent Object Oriented System Based On C++'', Proceedings of the Conference on Object Oriented Programming, Systems, Languages and Applications (OOPSLA), September 1993.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
...chares2
Chare (pronounced chär, ä as in cart) is Old English for chore.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... value3
Asynchronous remote method invocation is the core of CHARM++. However, to simplify programming, CHARM++ makes use of the interoperable nature of its runtime system, and combines seamlessly with user-level threads to also support synchronous method execution, albeit with a slight overhead of thread creation and scheduling.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... processor4
With its own, different address space
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... exists.5
The proxy class is generated by the ``interface translator'' based on a description of the entry methods
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... methods6
``Threaded'' or ``synchronous'' methods are different.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... Groups7
These were called Branch Office Chares (BOC) in earlier versions of Charm.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... code.8
Constraint: The C++ code cannot, however, contain global or static variables.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... CLASS="textsl">MOD.def.h.9
Note that the interface file for module MOD need not be named MOD.ci. Indeed one ``.ci'' file may contain interface declarations for multiple modules, and the translator will produce one pair of declaration and definition files for each module.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... CLASS="textsl">MOD.C).10
In the earlier version of interface translator, these files used to be suffixed with ``.top.h'' and ``.bot.h'' for this reason.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... processors11
Except when it is part of an array.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... message12
Threaded methods augment this behavior since they execute in a separate user-level thread, and thus can block to wait for data.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... created13
However, the element must eventually be created- i.e., within a 3-minute buffering period.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... opts.setAnytimeMigration(false)14
At present, this optimizes broadcasts to not save old messages for immigrating chares.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... opts.setStaticInsertion(true)15
This can enable a slightly faster default mapping scheme.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... NAME="3534">16
Originally called Branch Office Chare or Branched Chare
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... CLASS="textsl">ClassName.17
A deprecated older syntax allow them to inherit directly from the system-defined class Group
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... groups.18
As with groups, an older syntax has node groups inherit from NodeGroup instead of a specific generated class.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... NAME="4075"> 19
AtSync() is a member function of class ArrayElement
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... not20
Currently not all load balancers recognize this setting though.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... map 21
by default it always distributed array elements to processors in Round-Robin fashion unless a different CkArrayMap is used
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... displayed.22
Because of communication latencies, the following scenario is actually possible: Chare 1 does a CkPrintf from processor 1, then creates chare 2 on processor 2. After chare 2's creation, it calls CkPrintf, and the message from chare 2 is displayed before the one from chare 1.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... $%
\providecommand{\longcompilerfootnote}{$23
Most modern C++ compilers belong to one of the two camps. One that supports Borland style template instantiation, and the other that supports AT&T Cfront style template instantiation. In the first, code is generated for the source file where the instantiation is seen. GNU C++ falls in this category. In the second, which template is to be instantiated, and where the templated code is seen is noted in a separate area (typically a local directory), and then just before linking all the template instantiations are generated. Solaris CC 5.0 belongs to this category. For templates to work for compilers in the first category such as for GNU C++ all the templated code needs to be visible to the compiler at the point of instantiation, that is, while compiling the source file containing the template instantiation. For a variety of reasons, CHARM++ interface translator cannot generate all the templated code in the declarations file *.decl.h, which is included in the source file where templates are instantiated. Thus, for CHARM++ generated templates to work for GNU C++ even parts of the definitions file *.def.h should be included in the C++ source file.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... compilers24
Most modern C++ compilers belong to one of the two camps. One that supports Borland style template instantiation, and the other that supports AT&T Cfront style template instantiation. In the first, code is generated for the source file where the instantiation is seen. GNU C++ falls in this category. In the second, which template is to be instantiated, and where the templated code is seen is noted in a separate area (typically a local directory), and then just before linking all the template instantiations are generated. Solaris CC 5.0 belongs to this category. For templates to work for compilers in the first category such as for GNU C++ all the templated code needs to be visible to the compiler at the point of instantiation, that is, while compiling the source file containing the template instantiation. For a variety of reasons, CHARM++ interface translator cannot generate all the templated code in the declarations file *.decl.h, which is included in the source file where templates are instantiated. Thus, for CHARM++ generated templates to work for GNU C++ even parts of the definitions file *.def.h should be included in the C++ source file.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... runtime25
When CMK_ERROR_CHECKING is defined
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.