doc:machine model: edits for reviewing the section
authorChao Mei <chaomei2@illinois.edu>
Thu, 2 Aug 2012 23:17:01 +0000 (18:17 -0500)
committerChao Mei <chaomei2@illinois.edu>
Thu, 2 Aug 2012 23:17:01 +0000 (18:17 -0500)
doc/charm++/machineModel.tex

index 6b56522352b134eecff069df107168c8d4132d03..2dcc822cc39c310370893623ea76b3daf5503338 100644 (file)
@@ -1,5 +1,5 @@
 \section{Machine Model}
-At its basic level, Charm++ machine model is very simple: Think of
+At its basic level, \charmpp{} machine model is very simple: Think of
 each chare as a separate processor by itself. The methods of each
 chare can access its own instance variables (which are all private, at
 this level), and any global variables declared as {\em readonly}. It
@@ -13,7 +13,7 @@ chare objects).
 In accordance with this vision, the first part of the manual (up to
 and including the chapter on load balancing) has almost no mention of
 entities with physical meanings (cores, nodes, etc.). The runtime
-system is responsible for the mgic of keeping closely communicating
+system is responsible for the magic of keeping closely communicating
 objects on nearby physical locations, and optimizing communications
 within chares on the same node or core by exploiting the physically
 available shared memory. The programmer does not have to deal with
@@ -21,38 +21,46 @@ this at all. The only exception to this pure model in the basic part
 are the functions used for finding out which ``processor'' an object
 is running on, and for finding how many total processors are there.
 
-However, for implementing lower level libraries, and certin optimizations,
+However, for implementing lower level libraries, and certain optimizations,
 programmers need to be aware of processors. In any case, it is useful
-to understand how the Charm++ implementaiton works under the hood. So,
+to understand how the \charmpp{} implementaiton works under the hood. So,
 we describe the machine model, and some associoated terminology here.
 
 In terms of physical resources, we assume the parallel machine
 consists of one or more {\em nodes}, where a node is a largest unit
 over which cache coherent shared memory is feasible (and therefore,
-the maximal set of cores pver which a single process {\em can} run.
-Each node may include one or more processor chip, with shared or
+the maximal set of cores per which a single process {\em can} run.
+Each node may include one or more processor chips, with shared or
 private caches between them. Each chip may contain multiple cores, and
 each core may support multiple hardware threads (SMT for example).
 
-Charm++ recognizes two logical entities: a ``node'' and a PE
-(processing element).  In a charm++ program, one may partition a
-physical node into one or more logical nodes. What Charm++ calls a
-``node'' is this logical node. In the implementation, a separate
-process exists for each logical node. The RTS may optimize
-communication within a logical node by using shared memory. A PE is a
-unit of mappiong and scheduling: each PE has a scheduler with an
+\charmpp{} recognizes two logical entities: a PE (processing element) and 
+a ``node''.   In a \charmpp{} program, a PE is a
+unit of mapping and scheduling: each PE has a scheduler with an
 associated pool of messages. Each chare is assumed to reside on one PE
 at a time. Depending on the runtime command-line parmeters, a PE may
-be associated with a subset of cores or hardware threads. 
+be associated with a subset of cores or hardware threads. One or more PEs
+make up of a logical ``node'', the unit that one may partition a physical node
+into. In the implementation, a separate
+process exists for each logical node and all PEs within the logical node share
+the same memory address space. The \charmpp{} runtime system optimizes
+communication within a logical node by using shared memory. 
+%one may partition a
+%physical node into one or more logical nodes. What \charmpp{} calls a
+%``node'' is this logical node. 
 
-For example, on a machine with 16 core nodes, where each core has two
-hardware threads, one may launch charm with 32 PEs per (logical) node,
+For example, on a machine with 16-core nodes, where each core has two
+hardware threads, one may launch a \charmpp{} program with one or multiple
+(logical) nodes per physical node. One may choose 32 PEs per (logical) node,
 and one logical node per physical node. Alternatively, one can launch
 it with 12 PEs per logical node, and 1 logical node per physical
 node. One can also choose to partition the physical node, and launch
 it with 4 logical nodes per physical node (for example), and 4 PEs per
-node. zit is usually not a good idea to launch Charm with more PEs
-than there are hardware threads on each node. More information about
+node. It is not a general practice in \charmpp{} to oversubscribe the underlying
+physical cores or hardware threads on each node. In other words, a
+\charmpp{} program is usually not launched with more PEs than there
+are physical cores or hardware threads allocated to it. More information about
 these launch time options are provided in [manual for how to run charm
-apps] and [Chao's section on SMP related primitives in this manual].
-
+apps]. And utility functions to retrieve the information about those
+\charmpp{} logical machine entities in user programs can be refered
+in section~\ref{basic utility fns}.