EC++ - EUROPA Parallel C++. A Draft Definition

EC++ | EUROPA Parallel C++ A Draft De nition D. Caromel, P. Dzwig, R. Kau man, H. Liddell, A. McEwan, P. Mussi, J. Poole, M. Rigg, R. Winder The EUROPA Working Group on Parallel C++, Architecture SIG Abstract. This paper outlines a draft de nition for EC++. EC++ is a framework within which parallel C++ systems can be standardised. The framework will add portability to parallel C++ systems and will run across a variety of hardware architectures, while encompassing as wide a set of parallel computing models and paradigms as possible, both standard models and user extensible models. This is done entirely within standard C++, i.e. without syntactic extensions to C++. 1 Introduction 1.1 Structure of the Working Group The EUROPA Working Group on parallel C++ has been formed with a view to de ning a standard framework for parallel C++ systems. The members of this Working Group come from a variety of backgrounds|researchers into parallel C++, hardware vendors, compiler writers and end user application developers. Input has also been taken from other (non-participating) parallel C++ users and researchers. 1.2 Aims of EUROPA The aim of this standardisation work is to reconcile the various approaches to parallel C++, and to de ne a framework within which parallel C++ languages can be expressed and standardised. This will make parallel C++ systems more portable across hardware architectures and across compiler implementations, thus giving application developers the portability of code that is needed. It is not the aim of this work to attempt to standardise the number of computing models and paradigms that exist within the parallel C++ community. EUROPA will provide a standard framework where existing models can be implemented in a portable and ecient manner, and new or user/application speci c paradigms and models can be designed in a standard context. EUROPA will not de ne a parallel C++ language per se, or even an exhaustive set of parallel semantics per se; rather it will seek to de ne a set of standards and guidelines which language designers and compiler writers will need to consider and follow in order to have a parallel C++ language which can be said to conform to the standard. It is this framework for building these systems which is seen as the standard, rather than de ning the speci c content of these systems themselves. In language syntax terms, the standard is as de ned by ANSI/ISO C++ and EC++ (EUROPA C++) will not change this. EC++ is an abstraction of parallel C++ models, conformance to which should ensure that a parallel C++ application will run on diverse systems. 2 Rational of EC++ 2.1 Syntax and Semantics of EC++ An EC++ compliant system assumes the syntax and semantics of C++, and allows a set of semantic extensions to allow parallel code to be constructed and to allow parallelism to be expressed. There is no allowance within the EC++ de nition for any syntactic extensions to C++. This means that the syntax of EC++ is precisely that of standard C++, and that sequential C++ code is a subset of EC++, therefore allowing standard sequential C++ code to be included in the EC++ de nition. Whilst the syntax of EC++ is purely that of C++ the system will de ne the semantics of interfaces to and between its various components. Thus EC++ will de ne the interface between an external application and the components. 2.2 Hardware Architectures EC++ will provide a framework for parallel C++ systems across a variety of hardware architectures. The only assumption about hardware architectures is the minimalistic view that they will consist of a set of basic computing resources (processors) with some form of associated memory and storage. The resources themselves can be massively parallel systems, multi-processor machines, distributed systems single processor systems or any other architecture (as a result of Section 2.1). No assumption is made within the EC++ model that these resources are unique processor/memory pairs, shared memory processors or otherwise. EC++ will o er the user/application the possibility of a view of a single system which will hide the details of the architecture of the (potentially complex) systems underneath. 2.3 Control of Parallelism Di ering applications, problem domains and parallel processing models require di erent control abilities over the parallel constructs used in a program. These control requirements largely de ne the usage patterns of the language in question and will vary with the application in question. EC++ will support variants of common classes of C++ applications and with them any assumptions about usage patterns. EC++ is a generic standard for di erent parallel C++ languages and implementations, no assumptions can be made about any one speci c control mechanism. Instead, a means of allowing di erent control mechanisms within di erent parallel C++ languages should be possible, constrained only by any restrictions which C++ would impose on those control mechanisms. 2.4 Communications No assumption is made within the EC++ de nition about any communication methods and communications implementations, (that is to say no one communications library is assumed) due to the range of hardware architectures and the range of programming models that EUROPA is attempting to cover. It is clear, though, that objects within a parallel C++ system will require to communicate with each other to allow useful parallel code to be written, either in method invokations, in value passing, control issues or other, despite the fact that no one form of cummunication (i.e. communications library) is assumed. In addition to this, as no assumption can be made about the location of these communicating objects (i.e. on what hardware architecture they reside),EC++ should contain a generic communications interface and generic communications bindings which will allow communications between objects to be well-de ned operations. These bindings will provide interfaces to individual mechanisms such as PVM and MPI, although not assume that these will be the underlying librarys. As a result of the above, communications can then be constructed, de ned and implemented in speci c parallel C++ compilers/systems in the most appropriate manner for both the model of parallelism adopted in the system and the hardware platforms on which it is to be targeted. The communications interface need not be seen by application writers, but as EC++ will de ne interfaces/bindings to this layer, this will increase portability of applications code and compiler generated code across platforms and systems. By de ning only communications interface layers for parallel programming models and inter-object communications, EC++ avoids assuming that any given model adopted for a parallel C++ system is a message passing model, and instead will allow a variety of models. It is anticipated that as more models are de ned within the standard framework set out in this paper this area of the standard will grow and become more diverse|possibly to the extent that there will be a number of sets of bindings. The systems designers would be o ered the choice of the communications interface most closely associated with their model, thus still maintaining a level of compatibility with systems modelled on the same paradigms. The details of the communication bindings de ned and the issues addressed by EC++ are given in Section 6.1. 2.5 Systems libraries The EC++ de nition will contain a further library de nition which will de ne and standardise the systems library facilities required for parallel processing models. These libraries will de ne the API to the librarys which applications programmers can reasonably expect to be supplied with a particular implementation of the EC++ system. Some of these library functions may be common to all platforms, while some could be speci c to individual platforms. The behaviour of the libraries will exhibit the same behaviour in any model independent of the architecture upon which the model is being implemented. Systems libraries will include the standard ANSI/ISO libraries. Systems libraries will provide tools which encapsulate details and knowledge of the architecture of a resource; and which can make this information available to the proxy system. 2.6 C++ Libraries Some existing ANSI/ISO C++ library functions will require reimplementation within an EC++ environment, but the semantic view of these libraries should not change. These library implementation could (and indeed are likely to be) very di erent between di erent models and also between di erent hardware architectures. The details of the standard de nitions of both the systems libraries and the ANSI/ISO standard C++ libraries are covered in Section 6. 3 EC++ Model and Structure The EC++ model proposes the following structure: { A Proxy Model (Level 0) [Section 4] { A Set of Programming Models (Level 1); [Section 5]  Standard models e.g. MIMD, SPMD, BSP, etc.;  User extensible models. { A Standard Set of Libraries; [Section 6]  PVM, MPI libraries/bindings;  Math libraries etc.;  Parallel I/O;  Tool libraries (e.g. Performance and Correctness, Debugging tools, Load balancing, etc). { A Set of Hardware Models/Systems libraries (Level 2);  Interface to hardware resources: shared memory etc.; { A set of interfaces and their semantics to and between components of the de nition. 3.1 The EC++ Run Time Model Figure 1 shows in a diagrammatic form the basic architecture of the EC++ standard (the run time model). As the proxy model is independent of any parallel paradigm, it permits the building of libraries of concurrent programming models. The hardware model describes various machine speci c primitives, and permits portable implementations of user extensible models. - Libraries @@ @@ R Programming Models Level 1: @ e.g. Active objects, SPMD etc. Applications ? Level 0: Proxy Model      ?    C++ Runtime Hardware Model  Model Fig. 1. EC++ architecture ' $' $' $ & %& %& % C++ Application X XXXX ZZ XXXXX ZZ XXXXz ZZ ~ Proxy - Any C++ Compiler  Generator ? ? 1 ?    ?  3  ?     ?   C++ Libraries Fig. 2. Standard Libraries - Standard Linker >   Hardware Model EC++ compilation scheme: no changes to the compilers or tools 3.2 The Applications View Programmers of parallel applications, are concerned with application parallelism, and as such see and use the various high level Programming Models, and specialised Libraries. In contrast to this, programmers of parallel models and paradigms, i.e. implementors of EC++ are concerned with the Proxy Model and the Hardware Model. 3.3 Development of Programming Models The EC++ framework makes it possible for applications programmers to develop various application models, some very general, some very speci c and highly targeted, thus allowing EC++ to address a wide range of application domains. 3.4 The EC++ Compilation Model The compilation scheme of EC++ is presented in Figure 2: it emphasises the important point that no changes to the system compilers or tools are involved. Only non-intrusive pre-processing (the proxy generator) is required. It is important that this pre-processing is non-intrusive, that is to say that it does not change applications code, but rather only generates extra C++ code to be compiled with standard C++ compilers. 4 EC++ Level 0: The Proxy Model The proxy model permits the speci cation of proxy objects for standard C++ objects; it is based on meta-object techniques. Associated tools automatically generate the C++ code of the proxies. 4.1 Proxy Generation The Re ect class returns a meta-object (a proxy) for the type being passed in the constructor's rst parameter; type info is the standard rtti class of C++. All the calls issued to this object will trigger the execution of the method reify with the appropriate object of type Call as a parameter. Rei cation is simply the action of transforming a call issued to an object into an object itself; we say that the call is \rei ed". From this transformation, the call can be manipulated as a rst class entity, i.e. stored in a data structure, passed as parameter, sent to another process, and so on. class Reflect { protected: virtual void reify (Call* c) { c->execute (); } // A call reification void* operator new (size_t s, type_info& t) { ... } public: Reflect (type_info t, ... ) { ... } }; All the classes publicly inheriting from Re ect present this behaviour. class Call { public: virtual void execute (); List<Any>Any eff_params; // effective parameters member_id m; // member to be called Any object; // target object Any result_place; // result address }; 4.2 Class and Member Identi cations The Class info and Member info classes provide class and member identi cations in a distributed framework. Another issue is the capability to automatically achieve (un)marshaling of objects between processes and name spaces. class Class_info { public: class_id id; structure s; // system-wide valid identification // information on the class structure // for (un)marshaling of objects ... }; class Member_info { public: member_id id; // system-wide valid identification Class_info* return_type; // informations on the member ... }; These classes are Meta-classes which represent information on C++ classes. They conform to the design principle of the standard class type info which provides some basic information, and are designed with the intention of being extended according to speci c needs. By construction, class id and member id have a system wide validity (they can be passed as parameters between processes), while on each name space Class info* and Member info* pointers have a speci c value and implementation. Two functions: Class_info* class_map (class_id c); Member_info* member_map (member_id m); provide a mapping on a given address space between class and member identi cations and local Class info* and Member info* values. 5 EC++ Level 1: Library of programming models This section of the standard is where programming models are described and tted in with Level 0 Proxy Model. These models can be any of the standard programming models, such as BSP (Bulk Synchronous Processing), SPMD, MIMD and a variety of other processing models. In particular, user extensible models can be described using this section of the EC++ de nition. 5.1 Implementation of Programming Models Usually, these libraries will be implemented using the proxy model (for the sake of transparent remote access), and the hardware model (to generate portable implementation). However, in some very speci c libraries (usually strongly dedicated to a particular platform and/or application domain), a straight mapping from the proxy layer to the hardware can occur in order to avoid any overhead. 5.2 Interface to Model Speci c Features Other important aspects of parallel programming are con guration control, mapping of processes on processors, load balancing and a range of related issues. Speci c classes, de ned in the Library part of EC++ Section 6, will de ne a standard interface to such features. The programming models will then feature a portable implementation, and will supply at an applications level a view suitable to the particular model. 6 EC++ Libraries EC++ will include de nitions of libraries that must be included and issues relating to parallel libraries, de nitions of parallel I/O and other related issues. EC++ will de ne the semantics of these interfaces. 6.1 Communications EC++ will de ne standard interfaces (and their semantics) to communications libraries. It is expected that this will take the form of a set of bindings which relate to communications libraries such as PVM and MPI, and also any hardware speci c libraries which may be used. 6.2 Relation to CORBA Eventually, EC++ libraries will include an interface to the CORBA (Common Object Request Broker Architecture) of the Object Management Group (OMG). The proxy model will permit to automatically generate object description, and thus will allow for transparent access to a CORBA Object Broker. This section of the standard will be de ned in greater detail in the next version. 7 Summary To recap, EC++ does not de ne a parallel C++ language per se. Instead it de nes a standard structure allowing the programming of various parallel programming models within C++. A number of components of the system have been de ned. By de ning the relationship between these components and their roles within the standard it gives a basic structure to which standard parallel C++ environments can adhere, thus making portable and reusable code a more attainable goal. The de nition of the individual components and their tasks has been done in such a way as to allow their implementations to be targeted at a wide variety of parallel architectures and allow for any architecture speci c requirements that may be necessary. In the same way they have been de ned so as to allow as many parallel programming models and paradigms as possible to t in the standard| indeed a whole level of the standard de nition is available for the de nition of parallel models of computation within C++. In this way EC++ o ers a standard portable development environment within which the development of parallel C++ and applications can be done. References [Car93] D. Caromel. Towards a Method of Object-Oriented Concurrent Programming. Communications of the ACM, 36(9):90{102, September 1993. [GBD+ 94] Al Geist, Adam Beguelin, Jack Dongarra, Weicheng Jiang, Robert Manchek, and Vaidyalingam S. Sunderam. PVM (Parallel Virtual Machine): A Users' Guide and Tutorial for Network Parallel Computing. MIT Press, 1994. [MPI94] Message Passing Interface Forum. MPI: A Message-Passing Interface Standard, May 1994. [RW94] Graham Roberts and Russel Winder. UC++: Parallel and Distributed Programming with C++. Research Note RN/94/34, Department of Computer Science, University College London, 1994. Poster Paper presented at OOPSLA'94. [Win93] Russel Winder. Developing C++ Software. Wiley, 1993. This article was processed using the LATEX macro package with LLNCS style