doc/faq/groups.tex

   1 \subsection{\charmpp{} Groups and Nodegroups}
   2
   3 \subsubsection{What are groups and nodegroups used for?}
   4
   5 They are used for optimizations at the processor and node level respectively.
   6
   7 \subsubsection{Should I use groups?}
   8
   9 Probably not. People with an MPI background often overuse groups, which
  10 results in MPI-like Charm++ programs. Arrays should generally be used
  11 instead, because arrays can be migrated to acheive load balance.
  12
  13 Groups tend to be most useful in constructing communication optimization
  14 libraries. For example, all the array elements on a processor can
  15 contribute something to their local group, which can then send a combined
  16 message to another processor. This can be much more efficient than
  17 having each array element send a separate message.
  18
  19 \subsubsection{Is it safe to use a local pointer to a group, such as from ckLocalBranch?}
  20
  21 Yes. Groups never migrate, so a local pointer is safe. The only caveat
  22 is to make sure {\em you} don't migrate without updating the pointer.
  23
  24 A local pointer can be used for very efficient access to data held by
  25 a group.
  26
  27 %<li>
  28 %<b>If a Group is constructed from </b><tt>main::main</tt><b>, the constructor
  29 %gets called immediately on PE 0. Therefore, a Group constructor may create
  30 %another Group, and get a valid group ID back. Correct?</b></li>
  31
  32 %<br>Yes. Groups may create other groups in their constructor.</ol>
  33
  34
  35 \subsubsection{What are migratable groups?}
  36
  37 Migratable groups are declared so by adding the ``[migratable]'' attribute in
  38 the .ci file. They {\em cannot} migrate from one processor to another during
  39 normal execution, but only to disk for checkpointing purposes.
  40
  41 Migratable groups must declare a migration constructor (taking
  42 {\tt CkMigrateMessage *} as a parameter) and a pup routine. The migration
  43 construtor {\em must} call the superclass migration constructor as in this
  44 example:
  45 \begin{alltt}
  46 class MyGroup : public CBase\_MyGroup \{
  47   ...
  48   MyGroup (CkMigrateMessage *msg) : CBase\_MyGroup(msg) \{ \}
  49   ...
  50 \}
  51 \end{alltt}
  52
  53 \subsubsection{Should I use nodegroups?}
  54
  55 Almost certainly not. You should use arrays for most computation, and
  56 even quite low-level communication optimizations are often best handled
  57 by groups. Nodegroups are very difficult to get right.
  58
  59 \subsubsection{What's the difference between groups and nodegroups?}
  60
  61 There's one group element per processor (CkNumPes() elements); and
  62 one nodegroup element per node (CkNumNodes() elements). Because they
  63 execute on a node, nodegroups have very different semantics from the rest
  64 of Charm++.
  65
  66 Note that on a non-SMP machine, groups and nodegroups are identical.
  67
  68
  69 \subsubsection{Do nodegroup entry methods execute on one fixed processor of the node,
  70 or on the next available processor?}
  71
  72 Entries in node groups execute on the next available processor. Thus,
  73 if two messages were sent to a branch of a nodegroup, two processors could
  74 execute one each simultaneously.
  75
  76 \subsubsection{Are nodegroups single-threaded?}
  77
  78 No. They {\em can} be accessed by multiple threads at once.
  79
  80 \subsubsection{Do we have to worry about two entry methods in an object executing simultaneously?}
  81
  82 Yes, which makes nodegroups different from everything else in Charm++.
  83
  84 If a nodegroup method accesses a data structure in a non-threadsafe
  85 way (such as writing to it), you need to lock it, for example using a CmiNodeLock.