The Eiffel Parallel Execution Environment

EPEE is an object oriented design framework for programming distributed memory parallel computers. It contains a set of classes providing the communication and location facilities used to build parallel classes. Common data distribution patterns and computation schemes are factored out and encapsulated in abstract parallel classes, which are to be reused by means of multiple inheritance. Reusable parallel components include parameterized general purpose algorithms for traversing and performing actions on generic data structures.

Most current Eiffel compilers (eg. ISE, Tower, SIG, Eon) rely on the C (or C++) language to produce intermediate code. Consequently, compiling Eiffel code for a parallel machine is not really an issue, since all parallel platforms provide at least a C compiler in their software environment. The EPEE toolbox includes cross-compilation tools that mainly consist of script files whose role is to deal with compiler flags and options correctly.
Any application designed with EPEE can thus be compiled for any target processor (provided an Eiffel runtime system exists for this processor). EPEE also includes an interface to a highly portable communication library called POM (Parallel Observable Machine), providing sophisticated facilities for tracing a distributed execution.

There exists two levels of programming with EPEE: the class user (or client) level and the parallelized class designer level. The aim is that at the client level, nothing but performance improvements appear when running an application program on a parallel computer. Moreover, these performance improvements should be proportional to the number of processors of the parallel computer (linear speedup), which would guarantee scalability.

For a user of a library designed with EPEE, it must be possible to handle distributed or shared objects just like sequential ones. The problem is thus for the designer of the library to implement distributed objects using the general data distribution and/or parallelization rules presented in this paper. While implementing these objects, the designer must notably ensure their portability and efficiency, and preserve a ``sequential-like'' interface for the sake of the user to whom distribution and parallelization issues must be masked.
Consequently, whenever an object already has a sequential implementation, its distributed counterpart must have exactly the same behavior: each parallelized feature should leave a distributed object in the same abstract state as the corresponding sequential one. The goal is here to ensure the transparency for the user (the application programmer), to preserve the global semantics of the object (and most especially the semantics of its access), and to preserve its interface.