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