Hybrid Computing in Chapel
Background
Chapel is a new parallel programming language being developed by Cray Inc. with the goal of increasing supercomputer productivity by a factor of ten by the year 2010. Chapel strives to improve the programmability of parallel computers by providing a higher level of expression than current parallel languages do, and by improving the separation between algorithmic expression and data structure implementation details.
Chapel's current definition contains a "locale" concept that represents a unit of architectural locality containing processing elements and the memory that is "local" to them. For example, on a commodity cluster, each multi-core processor and its associated memory would typically be considered a locale. Locales are used by the programmer to specify where data should be stored and where computations should be run, either explicitly or in a data-driven manner. This allows programmers to tune for locality, which is so often crucial on large-scale systems.
Chapel currently assumes that a program's locales are all fairly homogeneous -- details like the amount of memory per node may vary, but in general the locales are assumed to be fairly similar. As machines become more heterogeneous and as advanced users spread their computations across multiple machines to take advantage of differing strengths, we believe that it could become valuable to support a richer locale concept that would permit different locale types within a single Chapel program.
CASS-MT Chapel Research
The heterogeneity research conducted under CASS-MT differs from the current Chapel work in that it focuses on the question of “coarse-grain” heterogeneity in Chapel—extending the locale type to represent multiple distinct, loosely-coupled processor types within a Chapel program. As an example, consider that some computations work best on a fine-grain multithreaded architecture like the Cray XMT while others are most efficient on a distributed memory machine with a commodity processor such as a Cray XT.
A goal of this work is to support the execution of a single Chapel program cooperatively across both of these architectures. In such an approach, the user would be able to specify the number of XMT and XT nodes/locales to run on, and then use Chapel’s standard concepts for specifying data and task locality to explicitly map each program element to the machine resource that best suits it. In this way the user can concentrate on high-level mapping decisions, relying on the Chapel compiler and runtime to manage low-level bookkeeping details such as generating the multiple executables and managing the inter-machine communication and synchronization.
