Executive Subsystem Project

Abstract

The project is devoted to the development of executive subsystem which is intended to be the lower level of all the field-oriented parallel programming systems we are going to create in the future.

Introduction

The development of scientific applications has two principal stages. The first one results in a mathematical model of the scientific problem and the second is the implementation of this model as a computer program. The scientist, if not belonging to the computer science, normally consider computers and programs just as tools to study his model, and the rule about the tools is that they must be easy to use and be adequate to the work they are used for. Most of the serious scientific tasks nowadays require computation demanding processing of huge amounts of data. This means that scientist can not do much without parallel computing. Parallel computing is the only adequate mean for modern scientific problems. However, use of the parallel computing is not easy when field-oriented tools are not available. This is because general parallel programming requires special knowledge which most of the natural scientists do not possess. Thus, our mission, as system parallel programmers, is to provide field-oriented tools for natural sciences. These tools are to appear in the form of field-oriented programming systems.

The number of the fields waiting for the tools is, most likely, infinite, and the reasonable thing we can do is to think about the features which all of this tools must have and further classify these tools according to the features peculiar to the classes. The implementation of this features is to be done once for the class of the tools and can be reused afterwards in particular field-oriented programming systems.

Place of the executive subsystem

The task of the programming (i.e. preparing a program for a computer) is usually partitioned between a programmer and a programming system and, when the algorithm is chosen, consists in the mapping of the objects of the algorithm into the resources of a target computing system. With the modern computing systems and, which is particularly prominent, with the parallel computers, this mapping can not be done statically, as the role of the dynamic factors influencing the computations is quite important for the effectiveness of the computations. Moreover, the mapping decision for a particular algorithm's object can not be done only once for the execution, because a situation can require, for example, to move the object from one computational node of a parallel system to another. On the other hand, the disadvantage of dynamic mapping decisions is that they take time from the essential computations, and thus must be avoided wherever possible with static decisions. This leads to two-level programming systems, where static decisions are taken by a compiler, and dynamic decisions are in the scope of the runtime support system or _executive subsystem_.

So far, it is clear that all the field-oriented programming systems, which we are going to build, will comprise a compiler and an executive subsystem. This is the first their common feature to mention. Now, we have to discuss whether we can determine the boundary line between a compiler and an executive systems generally, that is for all imaginable programming systems. This is can not be done in brief, and further just the main ideas are given. The full analysis is the subject of the separate paper, which is to be linked bellow when gets available.

For all programming systems, there must be some general features that strongly have to belong to a compiler part of the programming system and those which have to belong to the runtime support. Apparently, there also may be some general features which, depending on the field, must go to one of the subsystems, and also a compiler and a runtime support of a particular system may have their own specific features.

As we are interested first in the executive subsystem we start with discussing of its features. Here are the most evident and general functions which the executive subsystem of any parallel programming system must provide in the parallel program. Note that all these deal with dynamics.

The parallel program must be able to execute on the computers from some wide class of computing systems without demanding rewriting. This feature is known as portability. The list of examples of the classes includes MPPs, SMPs, cluster systems, networks of workstations, distributed systems, grids. Non-trivial classes require that parallel program be able to execute on heterogeneous systems as well as be able to cross security barriers within the grid systems.

The parallel program must be able effectively speed up with the growth of the available ccomputing elements. This is known as scalability.
The parallel program must be able to proceed with the computations and finish them successfully in the case of failures in parts of the hardware or system software. This is known as reliability.
The developement of fenomena modeled by the parallel program can lead to workload imbalance among the computing elements or exhaustion of particular resources (memory) in the elements, and parallel program must be able to redistribute among the element the objects of initial algorithm. This task is called load balancing.

Though these required features of all parallel programs can be stated generally, it is not easy to see whether they can be implemented once in a general but effective way and then be included into the future parallel programs. This is the point for our investigations.

It is also necessary to study examples of efficient parallel programs and find out their common features ans differences.

Relevant Links

Head of the project: Victor Malyshkin
Senior Developer: Maxim Gorodnichev