Charm++Data-driven Objects.ppt

Charm++Data-driven Objects L. V. Kale Parallel Programming Decomposition what to do in parallel Mapping: Which processor does each task Scheduling (sequencing) On each processor Machine dependent expression Express the above decisions for the particular parallel machine Shared objects model: Basic philosophy: Let the programmer decide what to do in parallel Let the system handle the rest: Which processor executes what, and when With some override control to the programmer, when needed Basic model: The program is set of communicating objects Objects only know about other objects (not processors) System maps objects to processors And may remap the objects for load balancing etc. dynamically Shared objects, not shared memory in-between “shared nothing” message passing, and “shared everything” of SAS Additional information sharing mechanisms “Disciplined” sharing Charm++ Charm++ programs specify parallel computations consisting of a number of “objects” How do they communicate? By invoking methods on each other, typically asynchronously Also by sharing data using “specifically shared variables” What kinds of objects? Chares: singleton objects Chare arrays: generalized collections of objects Advanced: Chare group (Used by library writers, system) Data Driven Execution in Charm++ Need for Proxies Consider: Object x of class A wants to invoke method f of obj y of class B. x and y are on different processors what should the syntax be? y-f( …)? : doesn’t work because y is not a local pointer Needed: Instead of “y” we must use an ID that is valid across processors Method Invocation should use this ID Some part of the system must pack the parameters and send them Some part of the system on the remote processor must invoke the right method on the right object with the parameters supplied Charm++ solution: proxy classes Classes with remotely invokeable methods inherit from “chare” class (system defined) entry methods can only have one parameter: a subclass of message For