doc: collapse intro text into one chapter
[charm.git] / doc / charm++ / machineModel.tex
1 \section{Machine Model}
2 At its basic level, Charm++ machine model is very simple: Think of
3 each chare as a separate processor by itself. The methods of each
4 chare can access its own instance variables (which are all private, at
5 this level), and any global variables declared as {\em readonly}. It
6 also has access to the names of all other chares (the ``global object
7 space''), but all that it can do with that is to send asynchronous
8 remote method invocations towards other chare objects. (Of course, the
9 instance variables can include as many other regular C++ objects that
10 it ``has''; but no chare objects. It can only have references to other
11 chare objects).
12
13 In accordance with this vision, the first part of the manual (up to
14 and including the chapter on load balancing) has almost no mention of
15 entities with physical meanings (cores, nodes, etc.). The runtime
16 system is responsible for the mgic of keeping closely communicating
17 objects on nearby physical locations, and optimizing communications
18 within chares on the same node or core by exploiting the physically
19 available shared memory. The programmer does not have to deal with
20 this at all. The only exception to this pure model in the basic part
21 are the functions used for finding out which ``processor'' an object
22 is running on, and for finding how many total processors are there.
23
24 However, for implementing lower level libraries, and certin optimizations,
25 programmers need to be aware of processors. In any case, it is useful
26 to understand how the Charm++ implementaiton works under the hood. So,
27 we describe the machine model, and some associoated terminology here.
28
29 In terms of physical resources, we assume the parallel machine
30 consists of one or more {\em nodes}, where a node is a largest unit
31 over which cache coherent shared memory is feasible (and therefore,
32 the maximal set of cores pver which a single process {\em can} run.
33 Each node may include one or more processor chip, with shared or
34 private caches between them. Each chip may contain multiple cores, and
35 each core may support multiple hardware threads (SMT for example).
36
37 Charm++ recognizes two logical entities: a ``node'' and a PE
38 (processing element).  In a charm++ program, one may partition a
39 physical node into one or more logical nodes. What Charm++ calls a
40 ``node'' is this logical node. In the implementation, a separate
41 process exists for each logical node. The RTS may optimize
42 communication within a logical node by using shared memory. A PE is a
43 unit of mappiong and scheduling: each PE has a scheduler with an
44 associated pool of messages. Each chare is assumed to reside on one PE
45 at a time. Depending on the runtime command-line parmeters, a PE may
46 be associated with a subset of cores or hardware threads. 
47
48 For example, on a machine with 16 core nodes, where each core has two
49 hardware threads, one may launch charm with 32 PEs per (logical) node,
50 and one logical node per physical node. Alternatively, one can launch
51 it with 12 PEs per logical node, and 1 logical node per physical
52 node. One can also choose to partition the physical node, and launch
53 it with 4 logical nodes per physical node (for example), and 4 PEs per
54 node. zit is usually not a good idea to launch Charm with more PEs
55 than there are hardware threads on each node. More information about
56 these launch time options are provided in [manual for how to run charm
57 apps] and [Chao's section on SMP related primitives in this manual].
58