HiPPO(ID:7850/)for High Performance Parallel Object-oriented visually algorithmic parallel programming language from Newcastle-Upon-Tyne References: INTRODUCTION Over many years, research has addressed the problems of designing and implementing software systems. Supporting tools have been developed, but the increasing demands of applications have kept the need for new tools and paradigms ahead of their supply. The object-oriented paradigm is often exploited by software engineers, and is supported extensively in design tools, database systems and programming languages. Object-orientation is seen as a highly beneficial engineering methodology, and interest in it continues apace even in high-performance applications where optimal efficiency is often preferred at the expense of overall software engineering. While object-orientation can significantly help the software engineer in some areas, support for exploiting parallelism remains relatively traditional in that the programmer is generally left to explicitly exploit and manage parallel threads of control. Object-oriented libraries and patterns can help [3], but designing and implementing parallel systems remains a complex task. Part of a solution may lie in the provision of graphical or visual design systems and languages, which seem particularly appropriate for parallel software systems since they permit the user to break away from textual (sequential) representations and to construct a more parallel solution to a problem using the two (or more) dimensions of a visual space. Ideally, the graphical language will naturally support the expression of parallel solutions to a problem, while the semantics implicitly handle many of the aspects of exploiting parallelism that hitherto have had to be dealt with explicitly by the programmer. This paper introduces the HiPPO (High Performance Parallel Object-oriented) visual language being developed at Newcastle. Following on from earlier PhD research [4] HiPPO is unique in its combination of a visual syntax with an object-oriented computation model based on the flow of object references. It is not a research objective in HiPPO to (re-)invent object-oriented features. So, classes, inheritance, dynamic binding, etc. in HiPPO are not novel, and are not discussed further. Our interests are in the visual notations for expressing parallel object-oriented computations, and in the flow-of-object-references model. The next sections describe aspects of the HiPPO notation, with particular emphasis on the support provided for specifying potential parallelism, and the features provided by the Integrated Development Environment (IDE) that is an integral part of the HiPPO system. Extract: HIPPO, HENCE, CODE etc THE HIPPO VISUAL LANGUAGE: OVERVIEW The HiPPO language, like several others, is graph-based, with boxes representing parts of a computation connected by arcs that control the computation in some fashion. Beyond this simple framework, however, there are many design decisions that face the visual language designer [5]. One of the main decisions concerns the arcs, and what they represent and carry. In the HeNCE visual language [6, 7], arcs carry control-flow signals that enable the execution of computations. In CODE [8, 9], arcs carry data values and the availability of data triggers computations (a data-flow model). Since a data-flow model was felt to provide a more natural model for implicit parallelism, it was chosen as the primary model for HiPPO arcs. However, HiPPO also provides control-flow arcs for specifying additional sequencing constraints on computations, although these are only expected to be of limited use (e.g. to sequence two printing operations correctly). Although HiPPO adopts a data-flow model, the model is different to many other data-flow languages in that it is references to objects (termed object handles) that flow through arcs rather than copies of data values. The HiPPO programmer operates in a shared object environment, where everything is an object, and all of the objects being manipulated are potentially available to all parts of the computation. The choice of a shared object-oriented computation model has a number of ramifications both for the visual language notation and for the run-time support. This section will concentrate on the language issues, and a later section will briefly address the run-time issues. The adoption of a sharing model (versus a value copying or message-passing model) has the standard advantages and disadvantages: the sharing paradigm is more familiar and easier to use, but requires care to be taken over the synchronized use of shared entities to avoid unintended side-effects due to concurrent accesses from parallel threads, while the distributed/ copying paradigm removes the need for detailed synchronization features and the possibility of inter-thread interference, but is less familiar and adds complexity and overhead from the need to copy and distribute data for processing, and to merge results together subsequently. In HiPPO many of the low-level synchronization requirements of the sharing model are delegated to the run-time system and do not require explicit manipulation by the programmer. (The run-time system is also responsible for implementing the semantics of shared objects when executing on a distributed-memory computing platform, as will be discussed subsequently.) In the multiply example, the three matrices involved can be shared across the parallel computations. All that needs to be communicated are object handles, rather than (larger) sets of data values comprising all or parts of the matrices being manipulated. The synchronization of accesses to the shared matrix objects or their constituent data members is not specified by the programmer but is handled by the run-time system. Moreover, the result matrix can be updated directly with the results of the multiplication, rather than requiring an additional stage to be specified by the programmer concerned with receiving and merging separate sets of results. It is recognized that an experienced programmer can provide additional information about objects and their use that can be used to optimize performance. One example is categorising read versus write accesses, which can be used to optimize object locking strategies. HiPPO permits the user to provide such information ? The Item Properties window in Figure 1 shows this for the input argument matrixB which is specified as being read-only. In addition, the multiply method itself has also been specified as being read-only since it does not change the state of the matrix object to which it is being applied. With such information, the compiler and run-time system can optimise the locking strategies applied implicitly to the shared objects, and could even choose to replicate objects if this could give performance advantages (for instance, if the parallel platform was a distributed memory system). HiPPO also allows the user to indicate when objects being used as arguments can be cloned (controlled by the selection boxes illustrated in the Item properties window in Figure 1). Cloning essentially provides an object-copying mechanism, which can be used by the programmer to explicitly generate new objects that can be used in parallel with the original object. Cloning information can also be used for optimization purposes - for example, to pass the value of an object of type integer rather than an object handle. Once made, all of these choices are indicated graphically in the HiPPO implementation graphs via different icon borders and colours, although the exact notation is not important for this paper. The boxes on the graphs specify the computation parts of the solution. In HeNCE and CODE, the boxes contain traditional procedural statements/expressions (e.g. in C or Fortran). However, in HiPPO these computations represent the invocation of a method on an object. Other boxes in HiPPO have more special-purpose roles, such as representing the creation of new objects, and conditional, iterative and parallel computations. These features are described in the following sections. |