% {{{  prop.tex
\documentstyle[titlepage,twoside]{article}
\setlength{\textwidth}{13.5cm}
\setlength{\textheight}{21.5cm}
\addtolength{\oddsidemargin}{-1mm}
\addtolength{\evensidemargin}{-15mm}

% {{{  newcommands
\newcommand{\bct}{\begin{center} \begin{tabular}}
\newcommand{\ect}{\end{tabular}  \end{center}}
\newcommand{\bd}{\begin{description}}
\newcommand{\ed}{\end{description}}
\newcommand{\be}{\begin{enumerate}}
\newcommand{\ee}{\end{enumerate}}
\newcommand{\bi}{\begin{itemize}}
\newcommand{\ei}{\end{itemize}}
\newcommand{\bq}{\begin{quote}}
\newcommand{\eq}{\end{quote}}
\newcommand{\bt}{\begin{tabbing}}
\newcommand{\et}{\end{tabbing}}


\newcommand{\Connexite}{Connexit\'{e} }

\newcommand{\taskdesc}[2]{\multicolumn{2}{l}{~~~~~~~~~task #1: \parbox[t]{4in}{#2}}}

%\newlength{\NBwidth}
%\setlength{\NBwidth}{\textwidth}
%\addtolength{\NBwidth}{-5mm}
%
%\newcommand{\NB}[1]{\vspace{\baselineskip}\noindent\framebox[\textwidth]{%
%		\parbox{\NBwidth}{\underline{\bf N.B.} \\ {\it #1}}}%
%		\vspace{\baselineskip}}

\newlength{\wpcol}		% for tables in 'Workpackages' section
\settowidth{\wpcol}{Univ. Southampton~~~~~}

\newenvironment{wptab}%
	{\renewcommand{\arraystretch}{1.2}%
		\begin{tabular}{@{}p{\wpcol}@{}l@{}}	\hline}%
	{\end{tabular} \renewcommand{\arraystretch}{1}}
% }}}

\begin{document}

% {{{  \title
\title{{\huge Esprit 1993}	\vspace{\baselineskip}	\\
	{\Huge High Performance Fortran Tools		\\
	(HPF-Tools)}		\vspace{\baselineskip}	\\
	{\huge Proposal, Part 2}}
\author{}
\date{}
\maketitle
% }}}

% {{{  \tableofcontents (and pagestyles)
\tableofcontents
\pagestyle{empty}
\newpage


\pagestyle{headings}
% }}}

\setcounter{page}{1}

% {{{  1. Summary -- ok
\section{Summary}

% {{{  the necessity of HPF

The recently completed High Performance Fortran (HPF) informal standard 
for parallel programming promises to revolutionise the use of multi-processor
architectures, especially distributed-memory MIMD systems.  
It is based on a simple and familiar programming language and offers
wide portability, a simple migration method for existing Fortran codes,
and the promise of high performance, so there is every chance that it will 
rapidly become one of the foremost languages for scientific and engineering 
applications on such platforms.  Indeed, the lack until now of a 
programming language with these desirable features for DM-MIMD architectures 
has been the main reason for their low user acceptance, despite their 
potentially high performance and cost effectiveness, so the future success 
of these architectures is strongly dependent on the success of HPF.

% }}}

% {{{  the necessity of tool support for HPF programming

However, writing efficient HPF code is by no means a trivial task.  
The programmer will need a good understanding of his program and of
the HPF execution model in order to map data effectively and avoid 
programming practices that severely impair efficiency.
Indeed, the high-level nature of the language means that it will be very 
easy to write hugely inefficient code.  
This suggests that automated support and guidance would be particularly
beneficial for HPF program development.  Another obstacle for HPF users 
in the near term will be the lack of a supporting development environment 
including execution visualisation, libraries, etc.  Therefore, the aim of 
this project is to develop tools and software for supporting HPF programming.

% }}}

% {{{  what the project does

In particular, the project will develop tools to help transform `dusty deck'
Fortran programs into efficient HPF.  These include tools to identify 
and help replace `old, deprecated' Fortran programming features that 
inhibit efficient parallel execution, to replace sequential code by 
more efficient (and clearer) data parallel array syntax and calls to
intrinsic and standard library procedures, and to assist the data mapping 
process.  As well as assisting HPF program development, these tools
will improve the quality and efficiency of the resulting HPF program, 
which is a crucial requirement for the success of HPF.

The project will also develop tools for analysing, monitoring and
visualising HPF program execution, and a library of advanced graphics 
routines that can be called directly from HPF programs and operate 
efficiently on distributed data.

Again addressing the issue of efficiency, another theme of the project 
is to investigate HPF compiler optimisation issues, which are largely 
unaddressed at the present time since HPF is still very much in its infancy.

The tools will be `packaged' with an advanced, professional graphical user 
interface, and integrated into a programming environment developed in an 
earlier Esprit project (GIPE II) that allows uniform access and easy 
interoperability of all of the tools, and the easy addition of new tools 
as they become available.  In addition, `unpackaged', separately operable
versions of the tools will be available.

All of the tools will be generic to all architectures supporting 
message-passing, and the program development tools will generally be 
applicable to all architectures.

Finally, an integral part of the project will be the evaluation of the 
tools and software on real applications by an independent member of the 
consortium (i.e.\ one not involved in tool development), providing 
feedback to the tool development.

% }}}

% {{{  what it doesn't do (compiler development), but inputs from elsewhere

It is not proposed to develop an actual HPF compiler in this project 
(which is already being undertaken in other Esprit projects), or to
tie any of the tools to a particular compiler.
However, the project will import (Subset) HPF compiler technology
that was developed elsewhere, as a basis for tool development.
% }}}

\newpage
% }}}
% {{{  2. Project Objectives -- ok
\section{Project Objectives}

% Partners contributions here are mainly absent or seem too detailed.

The principal objectives of the project are as follows:
\be
% {{{  \item To develop tools to assist the conversion of standard

\item To develop tools to assist the conversion of standard Fortran to HPF

These include new tools for bringing ``dusty
deck'' Fortran to a normalised form; for semi-automatic insertion
of HPF data-mapping directives; and for replacement of in-line
user code by HPF intrinsic and library functions.  These and other project
tools will have a uniform modern user interface.

As well as assisting HPF program development, these tools
will improve the quality and efficiency of the resulting HPF program, 
which is a crucial requirement for the success of HPF.

%[FROM BES\ldots]
%One such tool is an Intrinsics/library generator.
%HPF contains an extensive set of intrinsic and library procedures.
%The objective of this tool is to recognize code in Fortran programs
%that can be replaced by these procedures and to automatically perform the
%replacement. This will thus help in the migration of existing Fortran 
%applications to HPF.
% }}}
% {{{  \item To develop performance monitoring and visualisation tools 

	\item To develop performance monitoring and visualisation tools 
for HPF programs.

Performance visualisation has a proven track record in tuning message
passing code, and is likely to be a key enhancement in HPF programming
environments too.  Since HPF will be available on a wide variety of
DM-MIMD architectures, portable, system-independent tools are necessary
for the analysis of the program behaviour.

%[FROM SIEMENS\ldots]
%The users' acceptance of any informal standard like HPF is strongly
%enhanced by an adequate programming environment.  Since HPF will be available
%on a wide variety of DM-MIMD architectures, portable, system-independent
%tools are necessary for the analysis of the program behaviour. Todays
%visualisers are mostly too system-oriented and apart from exceptions
%like Paragraph not portable. Moreover they do not provide support for both
%data-oriented and execution driven views as we intend. These views are
%vital to get an integrated picture of the runtime behaviour
%and its potential for optimisation.
%
%[FROM TUM\ldots]
%One important step to get system-independent tools is the definition of
%common trace formats for different trace producing and trace consuming tools.


%[TUM -- NEW STUFF\ldots]
%common trace formats (and semantics) => basis for adapting existing tools
%for the HPF environment + reusage of HPF tools in other environments 
%task 2.1 (trace and cross-referebce data for HPF visualisation) will try 
%to prepare the way to common trace format standards 


% }}}
% {{{  \item To develop an HPF graphical library.

	\item To develop an HPF graphics library.

This will be a library of efficient graphics routines for run-time use,
which can be called directly from an HPF program.  It will contain a 
wide range of functions for 1-d, 2-d and 3-d visualization,
and the routines will be designed to be efficient on DM-MIMD computers 
where the data is assumed to be distributed among several processors.


%
%[IBM - NEW STUFF\ldots]
%The current 'state of the art' in run-time parallel Distributed Memory 
%graphics is the 2-d Library of Parasoft. This is not good enough for the
%needs of todays large 3-d models where in some cases the model can not
%fit on a single computer. The advance of the state of the art is to produce
%an easy-to-use advanced 3-d run-time graphics library that will be callable
%from High Performance Fortran.
%

% }}}
% {{{  \item To develop HPF optimisation techniques.

	\item To develop HPF optimisation techniques.

Under this heading comes a tool for HPF source-to-source optimisation,
based on an extensible data base of program transformations,
and one supporting user optimisation of the intermediate Fortran
code produced by HPF translators.  We also include a component
of work on optimised translation schemes here, supporting other
tasks.

%a tool to allow the user optimization of the intermediate code produced
%by HPF programming environments
%that perform source-to-source translation
%will be developed. This tool will allow the detailed investigation of the
%code produced by those programming environments.
% }}}
% {{{  \item To build an open ended programming environment in which separately

	\item % \mbox{} [FROM CONNEXITE---Gilles Kahn\ldots]
To build an open ended programming environment in which separately 
designed tools can cooperate, and a modern client/server man-machine 
interface gives a uniform and intuitive access to the system's functionalities.
The resulting environment will bring unprecedented support to the 
task of building HPF scientific software.

% Bloody hell.  Something vaguely appropriate for a change.

% }}}
% {{{  \item To test and evaluate this software.

	\item To test and evaluate this software.
% }}}
\ee

\newpage


% }}}
% {{{  3. Project Contribution to Esprit Aims and Objectives -- wow!
\section{Project Contribution to Esprit Aims and Objectives}

This project addresses the `Basic High Performance Computing (HPC)
tools and technologies' sub-domain of the Esprit Work Programme for 1993-4,
and in particular task 3.5.  The objectives of this sub-domain 
are described as:
\begin{quote}
\em	To improve and consolidate the environment in which software and 
applications for HPCN systems are developed, \ldots
\end{quote}
The HPF development and visualisation tools
are addressed specifically to this aim. They will
will improve any programming environment for HPF.

%[FROM BES\ldots] The HPF intermediate code optimiser, intrinsic/library 
%call generator and source to
%source optimizer are addressed specifically to this aims. The last two tools
%will improve and consolidate all programming environments for HPF. The first
%will improve and consolidate programming environments that depend on a
%translator.

\begin{quote}
\em	\ldots to encourage standardisation and common practices 
amongst a widespread group of vendors and users.
\end{quote}
The creation of tools for HPF encourages its widespread 
use and so its standardization.

\begin{quote}
\em	Architecture-independent programming, ease of programming, general purpose, 
and predictable high level of performance will be the main focus.
\end{quote}
The optimisation workpackage tools will develop address
performance issues, in a largely platform-independent manner.

\begin{quote}
\em     To provide generic software which eases the use of a wide range
of applications.  To continue to stimulate the development of
next generation HPCN hardware and software in accordance with user
requirements.
\end{quote}
The evaluation and validation work will ensure that these goals are met.

The aims of task 3.5 specifically are:
\begin{quote}
\em	Development of methodology, associated software tools and supporting standards
which will rationalise the development of software for parallel systems and 
satisfy the production requirements of commercial and technical applications.
\end{quote}
% {{{  %[FROM CONNEXITE---Gilles Kahn\ldots]
%[FROM CONNEXITE---Gilles Kahn\ldots]
% }}}
Rationalising the development of software for parallel systems is
the very reason for the  existence of a company like \Connexite. The
tools that we develop must scale up to the requirements of commercial
and technical applications. The tools's users are not
necessarily programming language or system architecture specialists.
The development must be guided by an intuitive interface  and alternatives 
must be presented in a simple manner.

%[FROM SIEMENS\ldots] 
Portable languages like HPF are best supported by portable tools for runtime
analysis. Thus architecture independent programming is supported. The
ease of program development is especially supported by visualisation tools
which are easy to learn and support the programming and analysis
process substantially.
Moreover application independent tools  provide generic, general purpose
software. Since they support a specific programming paradigm, the environment
of HPCN systems is improved.

%[FROM IBM (16/4/93)\ldots]
Run-time graphics is an important tool in a large number of fields.
Graphics has been widely used in both program and algorithm debugging.
Parallel graphics will thus be an important tool which will
rationalize the development of software for parallel systems.
%Due to the level structure of the graphics library, one can expect
%high performance (i.e. small overhead) in calling these routines on
%a number of different parallel processing systems (DM-MIMD).


\newpage


% }}}
% {{{  4. Dependencies and Relationships -- ok
\section{Dependencies and Relationships}

This project will inherit considerable technical experience
in building programming environments from the Gipe and Gipe II
Esprit projects, as well as the experience of \Connexite (a spinoff of 
Inria) in marketing Fortran development and reverse-engineering tools.

Technology from an HPF programming environment that is being developed 
by BES and partially funded in a Eureka project will be imported into the
project.  This will form a basis for the development of
source-to-source transformation tools (task 3.3, source code optimizer, 
and 1.3, intrinsic/library call generator) and an HPF intermediate code 
optimiser (task 3.4).

Southampton University will provide as input to the project a
subset HPF compiler (or rather a translator from HPF to Fortran~90
plus message-passing).  This is based on modification of a system
called `ADAPT', whose development was started in the Espirt PUMA
project.  It will be used as the basis for HPF compiler
optimisation studies in task 3.1, and in project years 2--3 it will be
used to implement trace generation for the visualisation work in WP2 
(tasks 2.2 and 2.3).  The front end of this tool will also be used in
the development of a `data mapping assistant' in task 1.2 in project 
years 2--3.

Southampton University will also provide as input to the project an
inter-procedural analysis tool for Fortran called `IDA', which
is currently under development in the Esprit CAMAS project and will
be completed by September this year.  This will be the basis for 
further development in task 1.1, to create an `inter-procedural normaliser'.

The `ParViz' project at IBM Bergen Environmental Centre will provide initial
input to this project.  ParViz was developed for message passing
computers and has worked with Trollius and PVM on both a Transputer
based parallel machine (IBM's Victor, experimental machine) and
networks of workstations.

Software arising from HPF-Tools will be directly useful to other
projects, especially those related to parallel porting of software.
In addition, the possibilities for use as training aids in the European
COMETT Training programs are numerous.

This project does not contain a component for monitoring and influencing
the further HPF standardisation activities planned for next year
(HPF-2).  However, this is the domain of another Esprit proposal called
PROPS, and it is planned that `HPF Tools' would keep abreast of HPF-2
developments via the involvement of two partners, Southampton and Telmat,
in both projects.  The proposed PROPS project, which is targetted to 
the expansion of the HPF specifications, would also benefit from the 
detailed information emerging from `HPF Tools', for example in the areas
of HPF performance issues, programming styles, optimisations, etc.

\newpage
% }}}
% {{{  5. Baseline and Rationale of the Project
\section{Baseline and Rationale of the Project}

% {{{  \subsection{Baseline}
\subsection{Baseline}

% {{{  background -- types of Fortran

Fortran has always held a dominant position in scientific
programming.  Relatively unambitious in scope
compared with more modern programming languages, its simplicity nevertheless
lends itself naturally to automatic optimisation.  A large
subset of typical scientific and engineering applications do not
essentially depend on features like pointers
and contemporary data encapsulation techniques.  Their absence has
facilitated extensive static analysis and consequent transformation.
This, in turn, has enabled successful automatic vectorisation of
sequential code, and more limited success with semi-automatic
parallelisation (cf {\em Vast}, {\em KAP}).

In an independent line of development, various vendor-specific data-parallel
extensions to the Fortran have been notably successful in exploiting
SIMD architectures.  The outstanding contemporary example is
perhaps Thinking Machines' {\em Connection Machine Fortran}.

Recent years have seen a number of attempts to combine features from
these two threads (vectorization and data-parallelism).  These systems
take Fortran 77 programs extended by directives prescribing data
distribution and alignment.  Typically, they target distributed-memory
MIMD rather than SIMD hardware.  Such systems can be viewed as tools
for automating the coding of an emergent paradigm in scientific MIMD
computation---{Single Program Multiple Data} (SPMD) programming.  They
relieve the programmer of the need to explicitly insert
communication.  Archetypical examples are Rice University's {\em Fortran-D},
and {\em Vienna Fortran}.

The focus of these efforts has shifted with the acceptance of
the Fortran 90 standard, which contains explicit syntax for expressing
data-parallel computation.  This facilitates the extraction of
parallelism---because the programmer can express parallelism explicitly,
there is a reduced requirement to depend solely on extensive static analysis
for isolating parallelism.
(Simultaneously, some of the limitations to Fortran mentioned above
have been relaxed).
However Fortran 90 does not provide any support for programmer-defined
{\em placement} of data.

% }}}
% {{{  background - HPF

In the last year the {\em High Performance Fortran Forum} (HPFF), a coalition
of many leading industrial and academic groups in the field of
parallel processing, has established an informal standard called
{\em High Performance Fortran\/} (HPF) for extensions to Fortran~90 
for data-parallel computations on multi-processor architectures.  In 
particular, HPF includes directives for specifying, at various levels
of abstraction, how program data should be distributed over virtual or
actual processor memories.  The standard is supported by a majority of 
vendors of parallel hardware, including Cray, DEC, Fujitsu, HP, IBM, 
Intel, Maspar, Meiko, nCube, Sun and Thinking Machines.
Several vendors have already announced their intention to develop
HPF implementations, including hardware vendors
DEC, Intel, Maspar, Meiko, Thinking Machines,
and compiler vendors ACE, APR, KAI, Lahey, NA Software, Portland and PSR.

An official subset of HPF has been defined to facilitate
early implementations.  It is expected that the first true Subset
HPF implementations, implemented as translators to Fortran plus 
message-passing, will appear at the end of 1993 or start of 1994.
% }}}

The consortium of this project brings together an impressive
range of experience relevant to programming in HPF.

% {{{  Soton

Since 1989, the University of Southampton has been involved in the research
and development of a system called {\em ADAPT} (``Array Distribution Automatic
Parallelisation Tool'') for automatically transforming Fortran~90,
supplemented by data distribution declarations, to code for distributed memory
message-passing architectures \cite{adapt}.  This research started in the
Esprit PUMA project, and has established Southampton as a leading
group in the field of research into HPF-like languages and their implementation.

The input language for this system, {\em Distributed Fortran~90},
may be considered, alongside {\em Fortran~D} and {\em Vienna Fortran}, as a
precursor of HPF.  Ours was the first research to study the
implications of Fortran~90 in this context, others having concentrated
on Fortran~77, and a technical report of this research was one of 
a few major input documents to the HPF activity \cite{adapt-tech}.

Southampton has had a significant input and influence on the development 
of HPF, through an active involvement in the HPFF group supported by the 
Esprit PPPE project.  Southampton's contributions to HPF include the 
\verb@PURE@ procedure mechanism, which relaxes some of the restrictions of an
otherwise predominantly SIMD programming model.







% }}}

% {{{  inria

\Connexite  was founded in January 1992 to provide a range of products
and services aiding in the development of scientific applications and
the management of large-scale Fortran applications.  Together with its
founding partners INRIA and SIMULOG, it boasts 120 man years of
research in interactive programming environments.  Their existing
products include the FORESYS (FORtran Engineering SYStem) line.

INRIA's expertise in programming environments began with the Mentor 
system and continued under the Esprit program with the Gipe projects, 
``Generation of Interactive Programming Environments'', Gipe (1984--1989) and 
Gipe II (1989-1993).  
In the area of Software Development Environments, the major international
conference is that of the ACM SIGSOFT SDE conference, which is held every 
two years.  Gipe II results, including system architecture, programming
environment techniques, and intertool protocol, have been presented at
the last three SDE conferences.

% }}}
% {{{  bes

While working for an American company, leading staff at BES designed
and implemented a complete Fortran 90 to FORTRAN 77 translator.  In
conjunction with native FORTRAN 77 compilers, the translator provides a
Fortran 90 programming environment portable across a wide range of
computers.  Currently BES is participating in a Eureka project.  There it
is responsible for producing an HPF programming environment based on
a translator. The programming environment will be complemented with a
source-level debugger and a profiler.

% }}}

% {{{  siemens

Siemens, who will take a leading role in the HPF ``performance
visualisation'' tasks of the project, have previously implemented a
visualisation and control environment called VISIT \cite{IlmWie93} for
DM-MIMD programming.  This provides a sound platform for visualising
parallel programs, as an adjunct to optimisation.  Extensive use of
VISIT during the Esprit II project EDS demonstrated how software
development may be rationalised by the use of adequate tools. Their
close collaboration with Ken Kennedy and his group (a driving force
behind HPF and state of the art parallel Fortran environments) will be
of considerable benefit in their role of developing an integrated
visualisation environment for the HPF community.
Their associated partner TUM brings to the project long term experience in trace
based monitoring \cite{Eichholz88} and trace compression.
Southampton also has considerable experience in the area of performance
visualisation systems, gained partly during the Esprit GENESIS project,
within which they developed tools to transform between different trace file
formats, as well as a generic visualisation tool based on ParaGraph.

% }}}

% {{{  ibm
IBM BSC have been involved in parallel computing, graphics and
large scale scientific computing since their foundation in 1986.
Their graphics research, which forms the baseline of their
contribution to this project, was driven by
the need to visualize the variables of models used in Environmenal Sciences.
A post-processor
graphics environment, ADVIZE (ADvanced VIsualiZation Environment),
came out of this work. ADVIZE is an interactive 3-d visualization
environment for analyzing and presenting scalar and vector data.
It has been used by a number of international labs.
They have parallel computing experience with both Shared Memory
and Distributed Memory computers.

% }}}
% {{{  telmat

Finally, Telmat Informatique have been involved in the design and
commercialisation 
of parallel systems since 1985.
Those years of designing and
constant refinement have provided them with a strong appreciation
of the needs of their end-users in terms of programming tools.
This puts them in a strong position to effectively evaluate
and provide user-oriented feedback concerning the tools
produced in the rest of the project.

% }}}

% }}}
% {{{  \subsection{Rationale}
\subsection{Rationale}

% {{{  bryan's initial bit

    HPF is a significant step forward from explicit SPMD programming
with message-passing, towards a style of programming familiar to the
ordinary Fortran programmer.  On the one hand quite general parallel
algorithms can be encoded, but communication is managed entirely
transparently by the compilation system.  On the other hand, the
language has been designed with a view to permitting direct
message-passing {\em implementation} on distributed-memory systems,
generally avoiding the overheads of simulated shared memory.

     However, writing efficient HPF code is by no means a trivial
task.  The programmer will need a good a understanding of what the HPF
mapping directives mean, in order to use them effectively.  Indeed, the
high-level nature of the language means that it will be very easy to
write hugely inefficient code.  Deceptively simple programs can
translate to code involving enormous amounts of communication.
The situation is aggravated by the fact that early implementations
are unlikely to be highly optimising---implementors are bound
to concentrate on providing the prescribed parallel semantics, before
they turn to optimisation.

     The project proposes to provide a set of tools for easing the
transition to HPF, and tuning and debugging HPF codes.

% }}}

% }}}

\newpage
% }}}
% {{{  6. International Standards
\section{International Standards}

%[FROM BES\ldots]
All the tools will comply with the HPF standard and their availability will
encourage the use of HPF.

%[FROM SIEMENS\ldots]
The visualisation tools will exploit where relevant, MPI, the
emerging standard for message passing interfaces.
For display, OSF/MOTIF will be adopted.

The graphics library will be initially written with X-windows/Motif.
Future development could include Open GL and Phigs.

%[FROM IBM (16/4/93)\ldots]
%Graphics: X-Windows/Motif, future, if the target user group is moving
%   in this direction: OpenGL and/or Phigs.
%   Communication: PVM, future, the direction of the target user group: MPI, 
%   EUI (?). 

The work on tool interfaces also eploits OSF/Motif.  The tool
communication protocol will exploit WAIS and
an industry client/server protocol (e.g., Tooltalk, CORBA).

\newpage





% }}}

% {{{  7. Description of the Project
\section{Description of the Project}

% {{{  preamble -- OK
This section describes each Workpackage in turn, and concludes
by presenting the main risks of departure from the proposed workplan
and their consequences.
% }}}

% {{{  \subsection{Workpackage 1: HPF program development tools} -- OK
\subsection{Workpackage 1: HPF program development tools}

% {{{  WP1 intro -- ok
% {{{  rationale

It is generally recognised that transforming an existing Fortran
code into an efficient HPF program is not simply a matter of inserting
appropriate data mapping directives.  Fortran programs often contain
features that, although they can be supported by HPF, can potentially 
lead to monstrous inefficiency.  Particular examples are:
\bi
	\item {\em storage associations\/} (connections between sets of 
variables due to equivalences, or disagreement of common block declarations 
in different program units).
	\item {\em sequence associations\/} across procedure boundaries
(e.g.\ passing an array element to a dummy array, or shape disagreement 
between actual and dummy arguments);
\ei
The presence of these features in an HPF code obviously greatly impairs 
the data mapping possibilities, and can {\em enormously\/} increase the 
amount of communication and reduce the potential for concurrency.  
Another consideration is that variables subject to such associations 
{\em must\/} be explicitly identified by \verb@SEQUENCE@ directives 
in an HPF program, this being an example where a legal Fortran program 
must be modified to make it a legal HPF program.

It is clear from these considerations that in general some rewriting of 
Fortran codes may be necessary before they can be converted to efficient
HPF.  Indeed, the HPF standard acknowledges this, saying that the HPF 
principle is to `rewrite once' to produce a code that is portable across 
all architectures.  It is also clear that this code conversion would be
facilitated, and its quality enhanced, by software assistance.

The aim of this workpackage therefore to develop tools that will assist
the user in converting a `dusty-deck' Fortran program into an efficient
(and elegant) HPF program.

% }}}
% {{{  2 stage conversion (dusty-decl -> improved -> HPF)

It is useful to decompose this process into two stages,
as shown in Figure \ref{duval-pic1}:
\be
	\item The `dusty deck' program is first transformed into
an `improved' style which is more suitable for conversion to HPF.  
The improved style would make extensive use of the new features of 
Fortran~90, both to avoid the pitfalls inherent in the restrictions 
of Fortran~77 (e.g.\ storage and sequence associations, which may be 
replaced by new `cleaner' Fortran~90 features), and because many of the new 
features can assist data-parallel execution and HPF implementation
(e.g.\ array syntax and intrinsics, explicit procedure interfaces).\footnote{%
	N.B.  Task 4.1 will investigate the relative benefits
of these and other transformations, which will feed-back to this workpackage.}

The improved code is basically still standard Fortran (-90).
It may optionally include a few HPF syntax extensions 
(i.e.\ \verb@FORALL@ statements and constructs and \verb@PURE@ procedures)
which provide enhanced facilities for express data parallel operations,
as well as references to HPF standard library procedures, but it does
not include any HPF data mapping directives.

	\item The `improved' Fortran program is then transformed into 
an efficient HPF program by adding appropriate data-mapping directives, etc.
\ee

% {{{  *** figure:  dusty-deck -> improved -> HPF ***
\begin{figure}[hbtp]
\begin{center}
\setlength{\unitlength}{\baselineskip}
\begin{picture}(12,12)

\put(6,11.5){\makebox(0,0){efficient HPF}}

\put(6,9.6){\vector(0,1){1.4}}

\put(6,9){\makebox(0,0){\fbox{\it data mapping}}}

\put(6,7){\line(0,1){1.4}}

\put(6,6){\makebox(0,0){\shortstack{`improved' Fortran 90 (possibly	\\
			with HPF syntax extensions)}}}

\put(6,3.6){\vector(0,1){1.4}}

\put(6,3){\makebox(0,0){\fbox{\it `code improvement'}}}

\put(6,1){\line(0,1){1.4}}

\put(6,0.5){\makebox(0,0){`dusty deck' Fortran}}

\end{picture}
\caption{Transforming `dusty deck' Fortran into efficient HPF \label{duval-pic1}}
\end{center}
\end{figure}
% }}}

There are several advantages to this two-stage transformation:
\bi
	\item In general the `improved' program is a more suitable
basis for conversion to HPF than the original (i.e.\ it will give rise
to a more efficient HPF program) on {\em any\/} architecture.  Therefore code 
`improvement' need only be done once for all architectures, while the 
optimal HPF data mapping tends to be more machine specific.

	\item It will also be cleaner, clearer and more concise. 
(E.g.\ experiments in converting some `Genesis' benchmarks to Fortran~90 
array syntax have shown a reduction in code size of up to 50\% and a 
large increase in clarity).
In other words, the optimisations proposed here are all `clean', in the 
sense of improving the code legibility (as opposed to some machine-specific
`dirty' optimisations which make the code illegible).

Therefore, the user may well wish to keep the `improved' version as the
`master' copy of the program.  If HPF syntax extensions are avoided, the
improved version will still be standard Fortran 90 and totally portable.

	\item The HPF data mapping will generally be affected by the
source code `improvement', e.g.\ the removal of storage associations
will influence the mapping of arrays.
\ei
% }}}
% {{{  summary of WP contents

The tools to be developed in this workpackage will perform the following 
functions:
\be
	\item `interprocedural normalisation', e.g.\ the identification 
and removal of sequence and storage associations as described above (task 1.1);

	\item replacement of code by references to Fortran~90 and HPF 
intrinsic procedures, and HPF and other standard library procedures (task 1.3);

	\item replacement of sequential code by data parallel code, 
e.g. Fortran~90 array syntax or HPF \verb@FORALL@s (task 1.4);

	\item semi-automatic HPF data mapping (task 1.2).
\ee
The first three fall into the `dusty-deck' $\rightarrow$ `improved' 
Fortran category, while the last helps to automate the actual HPF 
data mapping process.

The workpackage will also develop (in tasks 1.5 and 1.6) 
a uniform graphical user interface for these and other project tools, 
and integrate them into a programming environment that allows them to 
cooperate easily and allows new tools to be added when they become available.

% }}}
% }}}

% {{{  \subsubsection*{Task 1.1: Interprocedural normalisation} -- OK
\subsubsection*{Task 1.1: Interprocedural normalisation}

A tool will be developed to perform tasks that we call `interprocedural 
normalisation'.  (We have invented this name, as we are unaware of
any existing tool with a similar functionality).
It will use interprocedural analysis to perform the following functions:
\bd
% {{{  Sequence and storage association removal
	\item[Sequence and storage association removal.]
It will locate all occurrences of sequence and storage association, 
and in the latter case also derive `aggregate variable groups' as defined 
in chapter 7 of the HPF standard.

It will also suggest how these associations may be removed  
(e.g.\ by using dynamic arrays to replace the Fortran~77 technique 
of decomposing a single static `workarray' into multiple ones via 
storage association).
If the user declines the appropriate code modification the tool will 
be able to insert the appropriate \verb@SEQUENCE@ directives 
in the program and apply, or check compliance with, the consequent 
mapping restrictions.

% }}}
% {{{  Introduction of explicit procedure interfaces
	\item[Introduction of explicit procedure interfaces]
into the Fortran program and the introduction of optimisations consequent 
on this,  e.g.\ changing all HPF mapping directives for dummy arguments 
to the `descriptive' form.  This is a useful optimisation, as it allows 
argument redistribution to be performed by the caller, avoiding the need 
for the argument mapping to be checked at runtime on entry to the procedure.

The tool will also check that procedure references are consistent with 
their definitions, and check conformance with Fortran's anti-aliasing 
rules for arguments that are modified (which is necessary to preserve 
program correctness under the types of transformations performed by an HPF, 
or even a vectorising, compiler.)

% }}}
\ed
Data subject to the sequence and storage associations {\em must\/} be 
identified by \verb@SEQUENCE@ directives in HPF, so this analysis is mandatory.
These associations also imply restrictions on data mapping, and can 
{\em massively\/} degrade efficiency in distributed memory implementations,
so their removal should constitute a major optimisation; indeed, this
may well be the most beneficial code improvement for the purposes of HPF on
such architectures.
We do not know of any currently available tools to perform these functions
(e.g.\ Forge-90 and its associated HPF implementation, XHPF77, aim to
support such associations, albeit inefficiently, rather than removing them).

The tool will be based on further development of the `IDA' inter-procedural 
analyser from the Esprit CAMAS project, and will be completed one year 
into the project.
% }}}

% {{{  \subsubsection*{Task 1.2: Data mapping `assistant'} -- OK
\subsubsection*{Task 1.2: Data mapping `assistant'}
\label{map-assist}

This will be an interactive tool to assist the programmer in
selecting suitable HPF mappings (i.e.\ alignments and distributions)
for the data in standard Fortran (-90) codes, 
and then automatically generate the appropriate HPF directives.
It may be regarded as a practical and feasible intermediate step 
towards the longer-term goal of fully automatic data mapping, which is 
still very much at the research stage (and is being explored in Workpackage
5 of PPPE).

As well as helping to convert standard Fortran programs to HPF, this
tool might also serve as an `HPF tutorial' tool, especially if supplemented 
by small sample codes.

It would perform the following functions:
\bd
% {{{  Alignment generation

	\item[Alignment generation.]  The tool will
suggest array alignments based on inspecting the array accesses in the 
input Fortran program.  It will return a number of candidate alignments 
with a weighting for each, where this could be determined, based on an 
estimate of the ratio of aligned to unaligned accesses.
% }}}
% {{{  Template generation

	\item[Template generation.]  Given a program with its data
alignments explicitly declared, this will extract a smaller number 
of HPF templates to align the arrays to, and automatically generate 
the required directives.

% }}}
% {{{  Distribution generation

	\item[Distribution generation.] Given alignments to templates, 
this will inspect the data access patterns to suggest suitable candidate 
distributions (i.e.\ for each dimension: block, cyclic, block-cyclic
or undistributed).

% }}}
% {{{  Argument mapping propagation and procedure cloning
	\item[Argument mapping propagation and procedure cloning.] 
The tool will perform inter-procedural analysis to perform a
number of functions, e.g.:
\bi
	\item For a given procedure, it could show the set of actual 
arguments and their mappings (when defined) associated with each dummy 
argument.

It could also generate a number of clones of the procedure, each of 
which has its dummy arguments mapped identically to the corresponding
actual arguments for a particular set of calls, and replace those calls 
by calls to the appropriate clone.  
This is a desirable optimisation for frequently executed procedures 
if the number of different actual argument mappings is sufficiently 
small, as it avoids the overhead of either run-time 
redistribution (if the actual argument has a different mapping from the 
dummy) or the calculation of data location (if the dummy inherits its 
mapping).

	\item Alternatively, data mapping could be propagated in the
opposite direction---from dummy arguments to the corresponding actual
arguments at call sites.  This is the natural strategy when dealing
with a heavily-used procedure that has an `optimal' mapping for its 
dummy arguments.

	\item It can propagate the mapping of global data
throughout the program.

\ei

% }}}
\ed

The tool will require an HPF parser, which will be obtained from the 
Subset HPF compiler currently under development at Southampton, which will
be imported into the project.  The results of the research in task 3.1 on 
HPF compilation techniques will be used in determining optimal data 
distributions.

A `static performance estimator' for standard Fortran programs could 
usefully be used in conjunction with the data mapping assistant.  
Such a tool is being developed elsewhere (e.g.\ the SPE in CAMAS), 
and it is likely that the latter could be imported into the project 
with relatively little modification.  This would provide estimates of
the execution frequency of each statement and procedure, thus 
indicating critical procedures, code sections, data objects and
access patterns on which effort could be concentrated.

This might thus be imported into the project and integrated with the
data mapping assistant (via the environment developed in task 1.6)
towards the end of the project.
% }}}

% {{{  \subsubsection*{Task 1.3: Intrinsics / library call generator} -- OK
\subsubsection*{Task 1.3: Intrinsics / library call generator}

The use of intrinsic and library procedures is a good way of both
simplifying the programming of an application (complicate algorithms are 
implemented with just a procedure call), and of producing efficient code 
(the intrinsic and library routines are generally optimized 
for the specific architecture being used).

Fortran~90 greatly extends Fortran~77's set of intrinsics by adding a 
large set of intrinsic procedures for common array operations, and HPF 
adds a few more of its own.
HPF also incorporates a standard library of procedures to perform many 
useful operations in data parallel programming, which are more complex
than those covered by the Fortran~90 intrinsics (e.g. combining send, 
parallel prefix and suffix operations, sorting).
Finally, the most common numerical libraries for Fortran (NAG, IMSL, ...) 
will have parallel HPF versions in the future.

The source-to-source transformation system developed in task 3.2 will be 
used to implement an intrinsics/library call generator. This system will 
recognize portions of code (patterns) that can be replaced by references
to intrinsic or library routines, and will make the replacements.

Data-bases of patterns/actions will be provided for:
\bi
	\item the Fortran~90 array intrinsics;

	\item HPF intrinsics;

	\item HPF standard library procedures;

	\item some standard numerical library (NAG, IMSL, ...), one of
which will be chosen according to its availability and possible benefits.
\ei
% }}}

% {{{  \subsubsection*{Task 1.4: Adapting Foresys tools for HPF} -- OK
\subsubsection*{Task 1.4: Adapting `Foresys' tools for HPF}

`Foresys' (FORtran Engineering SYStem) is a scientific computing 
environment, generated from Centaur (see task 1.5), which is developed 
and marketed by \Connexite.
It is a group of tools to help users develop and maintain Fortran code.  
This includes tools for parsing, visualizing and
interprocedural type-checking (source validation) of code.
There are also tools that help to restructure code with Fortran~77 syntax 
(as well as numerous industrial dialects) into code with a Fortran~90 syntax,
and tools that aid in the maintenance and parallelization of code, 
e.g.\ dependency graph generation.  

This task will extend the existing Foresys tools to handle HPF features 
and directives/constructs.  For example, in addition to generating
Fortran~90 array syntax, the code restructurer will be extended to 
generate HPF \verb@FORALL@ statements and constructs, which may express 
more general data-parallel computations than standard array syntax can.

The work for this subtask would begin with adapting the parser and visualizer
currently used to HPF.  Also a tool called `Forest' (FOrtran RESTructurer),
which is a migration tool that eliminates old constructs such as \verb@GOTO@s
and arthimetical \verb@IF@s, would be updated.  Next we would move onto an
HPF dependency graph generation.  Finally, we would adapt the Foresys 
tools to the new intertool protocol (see task 1.6).  This would result in 
a first product, `Foresys/HPF', half way through the project.

% }}}

% {{{  \subsubsection*{Task 1.5: Building Modern Interfaces for Tools} -- OK
\subsubsection*{Task 1.5: Building Modern Interfaces for Tools}

The goal of this task is to provide modern interfaces to the separately
designed tools.   While all the tools can be operated separately, a successful
programming environment for HPF must provide a system in which the tools
can cooperate and the user interface provides a uniform and intuitive 
access to all of the tools' functionalities.  

This task will build on experience with an environment generator called 
Centaur, which was developed under the Esprit Gipe and Gipe II projects.  
The programming
environment technology uses a client-server approach, and the interface 
follows standards such as OSF/Motif and uses intertool communication 
techniques.  The latter involves both control integration, whereby tools
communicate in an event-driven style, and data integration, which allows 
the tools to exchange the necessary information in a standard manner.

This task is divided into three subtasks:
\be
	\item interfacing source manipulation tools (developed within the 
project);
	\item interfacing run time tools (developed within the project), and
	\item final integration and packaging of the HPF environment.
\ee

% {{{  1st subtask

The first subtask deals with source manipulation tools developed elsewhere
in the project.  
For code migration tools, one wants to see the original source code 
corresponding to a portion of generated code.  This is particularly 
important, as the user is not the author of the generated code.  
The interfacing with the HPF source-to-source optimization tool (task 3.3)
is particularly interesting.  The user is not a specialist and thus it is not
simply a matter of presenting a menu of transformations.  The idea is to
aid the user by presenting directly on the source code the places
where the different transformations apply, allowing him to view the 
resulting transformation, and then perhaps finally applying such a 
transformation to the code.  Note that an undo facility is important
for this type of tool, and that the user is establishing a dialogue
via the interface with the generator of the transformations.  That is, 
the communication with the tool is more complex since it is a real 
dialogue, in contrast with handling messages generated by a typical batch 
tool (e.g.\ a compiler).

The work in this subtask is obviously dependent on the other work packages.
It will begin with the first components available from the `dusty desk tools', 
and the prototype source-to-source optimization tool.  This will result in a 
prototype environment that interfaces with other tools within the project.
We will also provide documentation for the user interfaces developed.
% }}}
% {{{  2nd subtask

The second subtask deals with the run-time tools developed within
the project.  The work in this subtask will be centered around the `HPF 
intermediate code optimiser' developed in task 3.4.  In this case, one 
can imagine sending directives to the tool, e.g.\ for setting breakpoints.  
Here too there is an active dialogue between the interface and the tool.

% }}}
% {{{  3rd subtask

The third subtask will perform the final integration and packaging of the 
final versions of the project tools, and produce accompanying documentation
for the HPF environment (i.e.\ documentation for the interactive environment 
rather than the tools themselves).  The end product of this task will be 
the completed HPF environment as a product.
% }}}
% }}}

% {{{  \subsubsection*{Task 1.6: Inter-tool Protocol} -- ok
\subsubsection*{Task 1.6: Inter-tool Protocol}

% {{{  intro & rationale

Workpackage 1 develops a number of tools for HPF program development.  
Getting the various tools to communicate is an important task, e.g.\
to show the correspondance between the original and generated code 
when dealing with source transformation tools.

This task is intended to set up a communication protocol to be used 
between the various tools in the HPF environment.

Tools provide various services, such as transformations or analyses, on 
source code.  The output of one tool may then be used as the input for 
another and so on.  In this case, a modification to the source program 
will invoke a chain of transformations.   Note that fragments of code and 
locations in the source code must therefore be expressed in a uniform manner 
that all tools understand.

We will specify the interface needed for control integration 
(i.e.\ requests, acknowledgements) between various tools, and for data 
integration (i.e.\ module names, code fragments, source code locations)
when these tools communicate.  The latter entails a HPF 
abstract syntax specification.  It is not necessary for all tools to 
operate on abstract syntax trees as an internal data structure but rather
it is necessary for each tool to be able to communicate with the others 
in terms of such trees.  This is particularly important in an interactive 
setting.

The major advantage of this approach is that any tool encapsulated 
using such an interface can then be replaced by another tool that 
conforms to the interface.  Also the approach is open-ended: new tools 
may be added.

% }}}
% {{{  project summary: 3 phases

We breakdown this task into 3 subtasks or phases:
\be
	\item A specification phase to document the protocol used for control
integration.  As mentioned above, this will include an abstract syntax 
specification for HPF.  In addition, a technique is needed for indicating 
locations in the source code.  We will also define the protocol used by 
various tools within the environment, i.e.\ requests and acknowledgements 
that the tools can receive or issue.  

	\item An initial prototype implementation will be developed, based on 
the Sophtalk system (a control integration system that was developed in the 
Esprit Gipe II project, No.\ 2177).  Sophtalk uses an encapsulation technique 
similar to that of HP's Softbench and has successfully been used to integrate 
tools in programming environments in the Gipe II project.  Here we will use 
the Sophtalk protocol to connect various tools for the HPF environment.  This 
subtask will result in an initial product using the Sophtalk protocol.  

	\item We will examine the suitability of a more robust standard for
intertool communication, be it Tooltalk, CORBA, or a new intertool 
communication system that emerges as a standard, and then implement the 
communication protocol using this standard.  Finally, we will adapt the 
previous Sophtalk version of communication between tools to use the new 
protocol and integrate tools, which only become available at the end of the 
project.  This would result in a more robust final product.
\ee
% }}}


% }}}

% }}}
\newpage

% {{{  \subsection{Workpackage 2: HPF visualisation and graphics}
\subsection{Workpackage 2: HPF visualisation and graphics}

% {{{  Introduction

% {{{  visualisation and graphics

This workpackage consists of four tasks, three of which will together produce
an HPF performance visualisation system, and the fourth of which will produce
an HPF graphics library.  The library will be able to be used by programmers
to help visualise their data and, although no formal connection between its
task and the others has been made in the workplan, it is envisaged that the
exchange of ideas between groups working on different but related forms of
visualisation will prove fruitful.

% }}}
% {{{  visualisation background, justification, and levels of abstraction

Visualisation of program execution is one of the most valuable means of
program diagnosis and tuning.
A number of performance monitoring and visualisation tools have already
been developed for explicit message-passing programs executing on
DM-MIMD machines (e.g.\ ParaGraph), and have proved to be a useful aid
in optimising, debugging and generally understanding the behaviour of
such programs. Similar tools will also be extremely useful for HPF programs.
Since HPF does not contain explicit message-passing, the opportunity arises
to visualise program execution at a higher level than that of existing tools.
HPF implementations for message-passing systems will, however, ultimately
generate message-passing code, and we therefore propose to develop two tools
that enable programs to be visualised at three different levels of abstraction:
% {{{  Array, Process, Message-passing
\begin{enumerate}
\item Array level
\item Process level
\item Message-passing level
\end{enumerate}
% }}}
At the higher level, program execution will be able to be visualised purely
in terms of language-level distributed arrays, while at the lower level it
will be possible to observe the actual pattern of message-passing produced by
the code.  The process level lies somewhere between the two extremes, and
both tools will visualise aspects of it.

% }}}
% {{{  trace generation

The visualisation tools will display a representation of trace data generated
during program execution.  For array-level visualisation, the trace must be
generated by library calls embedded into the code by the HPF compiler, while
for the message-passing level it suffices that the trace be generated by
code within the message-passing library.  The two approaches are thus
complementary, with the higher level form of visualisation being easier
to comprehend, but less portable.  In contrast to existing visualisation
systems for explicitly message-passing systems, it is unavoidable that the
compiler itself must be instrumented if language-level visualisation is to
be achieved. In addition, the compiler must produce a cross-reference file
to relate trace data to the HPF program source.  In order to simplify the
task of instrumenting particular compilers we will produce trace and
cross-reference generating libraries that are as generic as possible, and
to demonstrate the system as a working whole, and to assess the
effort involved in instrumentation, we will produce an instrumented version
of Southampton's research implementation of a subset HPF compiler.

% }}}
% {{{  overview of visualisation system components

The relation between the visualisation tools and the other components of
the visualisation system is shown in Figure~\ref{vis-fig}.  Programs are
represented by rectangles, and their input and output data by ellipses, with
arrows indicating the flow of data between programs.  The rectangle
representing an executable program is an exception, since it is also data.
The dashed line on the arrow pointing to it indicates that it is the output
data of the compiler, rather than the compiler being its input data.  The
diagram actually illustrates the case of array-level visualisation.  The
equivalent diagram for the message-passing level is very similar except that
the trace generating routines are embedded within the MPI/PVM routines.

% }}}
% {{{  picture of visualisation system components
\begin{figure}
%\centerline{\psfig{figure=hpf-vis.eps,width=\textwidth}}
\begin{center}
%\fbox{\epsfxsize=\textwidth \epsfbox{hpf-vis.eps}}
\makebox{\epsfxsize=\textwidth \epsfbox{figs/hpf-vis.eps}}
\caption{Components of the HPF Performance Visualisation System}
\label{vis-fig}
\end{center}
\end{figure}
% }}}

% }}}

% {{{  \subsubsection*{Task 2.1: Trace and Cross-Reference Data}
\subsubsection*{Task 2.1: Trace and Cross-Reference Data}

% {{{  aim

The principal aim of this task is to select trace definitions which are
closest to emerging standards and to develop a library of basic trace
generation and reading functions which supports those trace definitions.

% }}}
% {{{  mixed approach to trace generation

For HPF monitoring we propose to adopt a ``mixed'' approach to trace
generation, to support the different levels of abstraction of
the visualisation tools.  To visualise message-passing (task 2.3)
only the message-passing library need be instrumented.  To visualise at the
array-level (task 2.2) the HPF compiler must insert trace generating code.
Trace events can then represent global operations,
which is conceptually simpler than trying to reconstruct global operation
semantics from message-passing level trace data.
Moreover, such a representation could significantly reduce the size of
trace files, which is already an important consideration, and increasingly
so as the speed of systems, and the number of processors in them increase.

% }}}
% {{{  X-ref

In either case, in addition to the information in the trace, the
graphical tools must be in possession of cross-reference data, relating
that information back to the source code, if language-level visualisation
is to be achieved.  This cross-reference data is static information, and
can be generated at compile-time.  The precise definition of the type of
cross-reference data required by the visualisation tools is intimately
bound up with the choice of level of trace data to be recorded.  Trace and
cross-reference generating libraries will be provided to embody the design
decisions that are made.

% }}}
% {{{  data compression

In addition to reducing the number of generated events, it is important
to minimize the amount of trace data logged with the events.
Minimizing trace data leeds to reduced overhead at run time (and
less influence on the program run), reduced communication costs (for data
collection), reduced disk usage, and faster trace interpretation.  TUM will
contribute their long term experience on trace based monitoring and trace
compression from the ParMod project \cite{Eichholz87,Weininger91,Friedrich92}.

% }}}
% {{{  staged plan

In the first stage, the trace file formats offered already by the partners
(e.g.\ EDS Lisp, VISIT) and undertaken by other groups
(e.g.\ PICL, SIMPLE, self-defining records, ParMod) will be analysed.
In the second stage, a trace format will be defined which is closest to
emerging standards and which satisfies the requirements of HPF visualisation.
Finally, a library of trace generation and reading functions will be
implemented (using data compression algorithms)
and integrated into the HPF tools supported.

% }}}

% }}}
% {{{  \subsubsection*{Task 2.2: Array-Level Visualisation Tool}
\subsubsection*{Task 2.2: Array-Level Visualisation Tool}

% {{{  general description

A tool will be developed that will present the programmer with performance
data in a graphical form related to the constructs used at the source code
level.  This is the same approach taken by currently popular tools for
message-passing programs, except that in the case of HPF the relevant
constructs are distributed arrays, rather than message-passing calls.
Thus the graphical displays used will be based on arrays
and their alignment with templates, the distribution of templates onto
abstract processors, and the allocation of abstract processors to
physical processors.  Animation and colour will be used to convey
performance data relevant to an HPF program.
This will include remote memory accesses and processor utilisation.
Although remote memory accesses are implemented by message-passing,
they will be represented in terms of array element accesses.
For portability the tool will be based on the X Window System, which runs
on systems available from a wide variety of vendors.

% }}}
% {{{  phases

Since at present there are no tools of this type, there is no base
of existing practice, and the first phase of this task will be concerned
with designing a suitable set of graphical representations to be implemented.
By the start of the project, if other tools have become available then the
features they offer will be considered in the design.  For example, it is
expected that the Prism programming environment from Thinking Machines will
incorporate some form of HPF visualisation. During the initial phase there
will also be heavy interaction with the definition of the trace and
cross-reference data being undertaken in task 2.1.  In the second phase a
prototype implementation of the design will be made.  In the final phase
an instrumented version of a subset HPF compiler will be produced, based on
a research implementation available at Southampton, and will be used to
evaluate the visualisation tool.  In parallel with these two activities, a
final version of the visualisation tool will be produced, incorporating ideas
arising from the evaluation.

% }}}

% }}}
% {{{  \subsubsection*{Task 2.3: Message-Passing Level Visualisation Tool}
\subsubsection*{Task 2.3: Message-Passing Level Visualisation Tool}

% {{{  tool based on VISIT

In general, HPF compilers will transform the HPF code to Fortran code with
calls to a library containing functions for process generation and
communication.  Within this task the instrumented compiler of task 2.2
will be used, which produces code for the popular PVM communication
library and later for the emerging message passing standard MPI.
A tool will be developed to visualise at these levels of HPF program
execution.  It will be based on an existing visualisation and analysis
tool VISIT~\cite{IlmWie93}, which will be provided to the project. It was also
used with great success within the Esprit-II project EDS for parallel Lisp
visualisation.

% }}}
% {{{  1st stage

In the first stage, PVM/MPI will
be annotated to produce VISIT events, and VISIT can be employed by the
implementators of HPF for debugging and analysis. It will be specifically
employable by task 3.4 to optimise message passing code.
This task lets the programmer do fine-tuning on message passing level,
a technique for which appropriate visualisations are essential in order
to check the unchanged semantics of the program.
There will be no need to make changes to the HPF compiler at this stage, as
all trace data can be derived from the PVM/MPI level by annotating PVM/MPI,
although in order to be able to relate
the PVM/MPI information back to the HPF code, a restricted use of the
cross-reference table produced by the HPF compiler will be necessary.
The tool will offer,
for example, the following visualisations: a tree of spawned processes, Pert
charts with communication, specific displays for the language's
communication and synchronisation constructs, load balancing, performance
statistics. These visualisations are valuable for the HPF programmer
to get a general feeling for the program performance.
The visualisation can be done both in realtime and post mortem out
of the trace file.
Since VISIT proved
to be easily adaptable to similar languages, other communication libraries
can be hooked to VISIT by the respective partner.

% }}}
% {{{  tool will evolve

The tool will evolve towards a higher-level HPF execution visualiser
and will adapt to the trace format defined in interaction with task 2.2 by
task 2.1.  To achieve this goal,
it will use cross-reference information provided by the compiler and runtime
data from the runtime system. Together with the information from the PVM/MPI
level, the tool will provide visualisations which are customized for
dataparallel language executions. For example, the typical split-join
behaviour of HPF programs can be presented to the HPF user for analysis.
Visualisations typical for HPF programs, e.g. processor grids, will
be integrated.  Task 2.2 will instrument an HPF compiler and can thus provide
information on typical HPF execution patterns.

% }}}
% {{{  further stage

In general, the programmer wants to have visualisations in order to
see whether the program does the desired work in general, and
to recognize imbalances and irregularities.
In a further stage, the tool will be extended to allow the
programmer to declare what kind of imbalances and irregularities he
is interested in. Thus the `normal' program behaviour can be cut out,
and only the `special', interesting points can be displayed and visualised.
For example visualisations can be activated only for situations where there
is a specified deviation (e.g. in runtime or nonlocal memory accesses)
from the normal behaviour. This extension will heavily facilitate the
evaluation of the tools developed in work packages 1 and 3.
This will make the search for irregularities and performance
bottlenecks much easier and allow for faster program tuning.

% }}}

% }}}
% {{{  \subsubsection*{Task 2.4: HPF graphics library}
\subsubsection*{Task 2.4: HPF graphics library}

 % {{{  rationale
 Graphics is becoming increasingly important as the sizes and complexities
 of problems are increasing. The ability to grasp a large amount of data by
 using graphics is a tremendous aid to programmers.
 
 There is a problem with using today's run-time graphics routines on
 DM-MIMD processors since all of the data we wish to view graphically
 must reside on one processor, whereas in the HPF model data are spread
 out among the processors, and for efficiency are kept in the same place
 as much as possible.
 
 Due to the ratio of computing speed to communication speed (e.g.\
 presently $\sim$ 50--100 double precision Mflops versus $\sim$ 40--50
 Mbytes/sec for high speed connections between superscalar workstations)
 it is still quite costly for such computers to do much communication.
 If one wants to visualize large amounts of data located on separate
 processors during program runs it is important to reduce the amount of
 data transferred in order to optimize performance.  This will still be
 true even when the communication bandwidth increases.
 
 % }}}
 % {{{  overview
 
 We propose to build a graphics library that uses the underlying communications
 routines to produce graphical output of data situated on separate processors
 while minimizing communication.
 The library routines will be callable directly from the HPF program, and
 will thus hide from the programmer the inter-processor communication needed
 to combine data.  The library will do data reduction on the processors to
 reduce communication time and will use efficient algorithms to combine
 3-D data properly for hidden and transparent surfaces.
 
 The library will communicate with a `Graphics Daemon', a process that is
 responsible for the collection of reduced data, combination and preparation
 of this data, and the display. The schematic diagram below illustrates
 this process.  The programmer calls graphics subroutines on the top left of
 the figure. The graphics routines use the parallel graphics primitives
 and the communication routines. The graphics communication layer is one layer
 above the communication software layer in order to make the system
 easily portable. To go from one system such as PVM to another, for example,
 MPI, one need only change a small number of routines in one file.
 
  % {{{  piccy
  \begin{center}
  \setlength{\unitlength}{\baselineskip}
  \begin{picture}(31,10.5)
                                                            \put(19.5,8.5){\shortstack{graphics server \\ (hidden from user)}}
  
  \put(8,6.5){\makebox(0,0){HPF graphics routines}}               \put(23,6.5){\makebox(0,0){graphics system (X-windows)}}
  
  \put(8,6){\vector(0,-1){1}}                                     \put(23,5){\vector(0,1){1}}
  
  \put(8,4.5){\makebox(0,0){parallel graphics primitives}}        \put(23,4.5){\makebox(0,0){server graphics layer}}
  
  \put(8,4){\vector(0,-1){1}}                                     \put(23,3){\vector(0,1){1}}
  
  \put(8,2.5){\makebox(0,0){parallel graphics communication}}     \put(23,2.5){\makebox(0,0){graphics server communication}}
  
  \put(8,2){\vector(3,-1){3}}                                     \put(20,1){\vector(3,1){3}}
  
                            \put(15.5,0.5){\makebox(0,0){communication layer (PVM, MPI)}}
  
  \end{picture}
  \end{center}
  % }}}
 
 The graphics server is sitting on the `host' machine, i.e.\ the machine
 used to communicate with the X-windows graphics on the screen. Presently
 X-windows is being used as the graphics standard, however OpenGL and others
 will also be considered.
 
 % }}}
 % {{{  describe functions
 The HPF graphics library will be based on future development of
 the ParViz (`Parallel Visualization') system, which is based on PVM
 and X-windows.
 The library will contain functions such
 as setting colors and manipulating graphics windows.
 Different data can be displayed in different windows.
 The 2-d graphics functions will include basic functions such as lines,
 polylines, text, etc, and additionally higher level routines such as
 contours, fields/arrows, drifters, bars and different projections (rectangular,
 polar, etc) will be provided.
 The 3-d part of the package allows the display of
 3-d surfaces with independent contours, 3-d lines, fields, drifters,
 shading, and volume visualization with transparent `clouds' (single
 ray raytracing). Concurrent display of multiple grids (cartesian,
 spherical, etc.) will also be possible.
 
 Owing to the background of the people involved in this task,
 the initial emphasis will be the types of displays used in environmental
 modelling (airpollution, ocean-circulation, toxic spread).
 However, these needs will coincide with a large group in the science
 community, and it is our aim to produce a general package for
 scientific and technical applications. The other partners in
 this consortium will be a great resource by giving us feedback on
 the direction of advanced graphics functions.
 % }}}
 % {{{  summary of workplan
 
 The devlopment will be performed in the following phases:
 \bi
    \item By the end of the first year we plan to have a first
 prototype ready which includes a basic 2-d and 3-d components.
 This version will be based on X-windows graphics and PVM communication tools.
 The integration with HPF will also be planned.
 The communication layer must be made available for this to be done.
 
    \item The next year will be used to integrate the prototype with HPF.
 
    \item The third year will be devoted to advanced graphics routines
 and high level interaction routines, e.g.\ the ability to change view
 angle from the screen;  a method of saving pictures for movie making;
 and making printer interfaces for colorgraphics printers.
 
 \ei
 % }}}

% }}}







% }}}
\newpage

% {{{  \subsection{Workpackage 3: HPF optimisation} -- OK
\subsection{Workpackage 3: HPF optimisation}

     Code optimisation has traditionally been the province of
compilation systems.  Recent years, however, have seen an emerging
trend towards implementing very high-level languages (of which HPF is
an instance {\em par excellence}) by source-to-source translation to
other high-level languages.  At the same time program transformation
systems which perform optimisations at the original source level, have become
increasingly prevalent.  Hence, even without a specific commitment to
compiler development, there is a niche for optimisation tools
within the project.  One task here, namely 3.3, is committed to source to
source transformation {\em within} HPF.  Another, 3.4, supports user
optimisation at the intermediate code level (the message-passing code
generated by an HPF translator).  The first is, in principle,
completely independent of the HPF compiler.  The second involves
limited integration with a compiler (translator).

     Other workpackages (notably the tasks on language level
performance visualisation) will ultimately involve {\em some} level of
integration with an HPF compiler.  Wherever such compiler dependence
occurs, the intention is to clearly delimit and document the
requirements of the compiler, so that appropriate ``hooks'' can ultimately
incorporated in product compilers, developed outside the HPF Tools project.  As
an interim measure, existing experimental translators, imported into the
project by partners, will be used as a testbed for supporting tools
with compiler-dependent features.  Task 3.1, on translation schemes,
involves a component of ``testbed'' compiler support for other project
tasks.  Task 3.1 will also track and contribute to state of the art
HPF translation schemes.  The associated knowhow is needed within the
project, because other tools cannot expect to generate efficient HPF
code without some idea of the costs (for HPF, {\em strongly} dependent on the
translation scheme) of particular language constructs.

     Task 3.2 provides general support for source-to-source
transformation tools, needed within this task and also in
workpackage 1.

% {{{  \subsubsection*{Task 3.1:  HPF Translation Schemes}
\subsubsection*{Task 3.1:  HPF Translation Schemes}

% {{{  preamble

Although the main thrust of the project is on tools and other software 
for facilitating HPF program development, there
will be one task on translation (compilation) of HPF.
There are several good reasons for including such a component
in the project.
\bi
	\item Tools such as the semi-automatic data-mapping tool (task 1.2)
are strongly dependent on the translation scheme adopted by the target 
compiler.  Depending on exactly how communication is managed and
computation localised, different distribution schemes will be optimal.
So, at the very least, the project will have to track the
state of the art in HPF compilation strategies,
to make sensible decisions in design of the program-development
tools.

	\item Workpackages on language-level visualization and
performance monitoring will ultimately require compiler integration.
Availability of a research compiler within the project will
serve as a testbed for this integration.  Emphasis will be
placed on performing the integration in a modular way, so
that eventually the tools can be adopted by commercial compiler
vendors with minimum modification to their products.

	\item HPF-like systems are still in their 
infancy, and there has been little study of optimisation issues.  
Research is urgently needed into efficient implementation of the complex 
HPF semantics.

\ei

Southampton expect to have a research implementation of Subset HPF 
available at the start of the project, which will form a suitable 
platform for further development within the project.
The compiler will generate Fortran~90 output, with calls
to MPI-compatible communication routines.

% }}}

Specific areas of development in HPF translation to be addressed in this
task include:
\bd
% {{{  \item[Calculation Placement.]
	\item[Calculation Placement.]

Develop methods to determine the optimal placement of sub-expression
calculation, so as to minimise communication, minimise temporary storage, 
and increase potential concurrency.  By suitably organising the placement
of calculation it is possible to improve all of these aspects
simultaneously.
% }}}
% {{{  \item[Buffer Allocation.]
	\item[Managing local and non-local data in loops]

    In many cases, especially with problems involving some locality of
reference, \verb$DO$ loops can profitably be split into parts operating
on local data and parts involving communication.  This may facilitate
overlapping of communication and computation, and make calculations on
internal data simpler (vectorisable?).  The various proposed schemes
for managing this loop reorganisation need to be assessed.
 
%To develop and implement criteria for selecting between various
%possible schemes for organising calculation and communication, once the
%placement of calculation has been determined.  For example, suppose
%arrays $A$ and $B$ are aligned and the following DO-loop appears in the
%program:
%\begin{verbatim}
%  DO i = 1,n
%    A (i) = B (i-1) + B (i+1)
%  ENDDO
%\end{verbatim}
%This is typically parallelised by placing
%a segment of the loop range on each processor.  Communication
%is required at the edges of these segments.  Two basic strategies
%are to use collective shifts to make two copies of the $B$
%array, or just to copy the data on the edges from the adjacent processors.
%In the latter case the edge data can be copied into an ``overlap
%area'' made by declaring the locally held array segment to be 
%sufficiently large to accommodate the off-processor data,
%or the communicated data can be copied to specifically allocated
%temporary storage.
%
%Which of these assorted schemes is optimal depends on a number of
%circumstances, including system (i.e.\ compiler and harware) parameters
%such as calculation and communication parameters, and criteria 
%need to be developed to select the most likely candidate in any context.

% }}}
% {{{  \item[Layered Run-time Systems and Optimisation.]
	\item[Layered Run-time Systems and Optimisation.]

In certain places in HPF code almost no information is statically
available concerning the whereabouts of particular array elements.  In this
case data is accessed by very high-level run-time libraries
(perhaps performing collective operations on distributed arrays), with a
large performance penalty.  At the opposite extreme, on sufficiently
simple code an optimising compiler may be able to go straight to low
level communication instructions (below the level of standard message
passing interfaces).  The ``onion-skin'' approach involves
a layered run-time library, some representation
of which is available to the compiler, and whose procedures can be
``in-lined'' and simplified level by level when appropriate static
information available to the compiler.
We propose to explore the feasibility and utility of this
approach to communication management.
% }}}
\ed
Accordingly this task will
\begin{itemize}
  \item Track developments in the state of the art of HPF compilation.
  \item Investigate the issues described above, including experimental
implementations of the various schemes.
  \item Provide testbed compiler support to other tasks requiring
compiler integration.
\end{itemize}
Reports will be produced at yearly intervals.

% }}}
% {{{  \subsubsection*{Task 3.2: Generalised Fortran source-to-source transformation system} -- ok
\subsubsection*{Task 3.2: Generalised Fortran source-to-source transformation system}

% {{{  intro & background

Many modern programming tools operate by taking as input a program in a 
high-level language and writing as output an equivalent program in the same
language. Examples of such tools are source-to-source optimizers,
vectorizers, parallelizers and in general any tools that instrument programs.

The program transformations those tools perform are
traditionally hardwired in the code of the tool itself.
This has several drawbacks:
\bi
	\item To change or add a transformation
one needs to modify the code of the tool itself and recompile it.

	\item Incorporating program transformations as code within
the tool itself is not a natural way to express them.  The code
that implements a given transformation can be quite obscure and error prone.

	\item Users cannot modify the behavior of the tool and in general 
it is quite complicated and laborious to put more knowledge into the tool.
\ei

An alternative approach is to define a high-level language specifically
designed to express program transformations and then implement a generic
tool that can interpret that language and apply the program transformations
that it expresses.

BES are currently using this approach to implement an HPF to Fortran 90
translator in a project that aims to produce a programming environment
for HPF, consisting of the afore-mentioned translator plus a profiler and
a debugger. The system is still in its early stages, and targetted to some
specific, simple transformations.
% }}}
% {{{  work in task

In this task we will generalize the basic system, making it applicable to more
general program transformations.

The system consists of:
\bi
	\item a data-base of patterns to match (along with the
actions to do upon finding each pattern);
	\item a tool that reads the data-base and the original source, 
looks for the patterns and performs the required actions.
\ei

For the purposes of this project the system will be extended and improved in
three different ways:
\be
	\item {\bf Extension and enhancement} of the basic system 
to perform the tasks required for this project.  The system will need
to recognize more complicated patterns, and to perform more complicated actions
on finding those patterns.  The work will involve extending the
language used to specify the patterns and actions as necessary, and
implementing those changes in the actual system.

	\item {\bf Conversion into an interactive system.}
The basic system works as a batch system.  An interactive user interface 
will be added, using the techniques and tools developed in tasks 1.5 and 
1.6.  This will allow the user to perform all tasks interactively
and to see and act on the patterns and actions which the system performs.
The concept of a hierarchy of data-bases will be introduced, and the user 
will be allowed to create his own data-bases.

	\item {\bf Optimisation of the system.}
The main bottleneck of the system is in the pattern matching algorithm. 
One needs to compare each portion of the parse tree with a data-base of
possible patterns to match. Those data-bases can be very large, and they 
will keep growing as more knowledge (pattern/action rules) is put into 
the system. To overcome this bottleneck the pattern matching algorithm 
itself will be optimised.
\ee
% }}}
% {{{  rationale

By building different data-bases, several source-to-source code transformation
tools will be created.  These can be seen as different tools, depending
on the emphasis given to the different functions performed,
and the data-base used.

This task is thus a supporting task for tasks 1.3 and 3.3.  Specific source to
source program transformation tools will be created by writing
suitable data-bases of program transformations.  There will also be feedback
from tasks 1.3 and 3.3 into this task, indicating how the system needs 
to be extended to perform the more complicated program transformations 
required therein.  The basic system, already developed, will enable the 
simultaneous start of all these tasks.

One of the strong points of this system will be its expandability: the
user will be able to easily create his own data-bases or to add or
replace rules in existing data-bases.

% }}}
% }}}
% {{{  \subsubsection*{Task 3.3: HPF source-to-source optimiser} -- ok
\subsubsection*{Task 3.3: HPF source-to-source optimiser}

Optimization of high-level programs is usually done in one of
two ways.  The compiler may create optimized object-code directly, by
analysing the program and internally applying program transformations 
that optimize the code.

The alternative is to use a source-to-source optimizer. In this case the
program, written in a high-level language, is read and analyzed.
The optimizer then finds program transformations that optimize the code
and outputs the resulting program in the same high-level language.

In this task we will develop such a source-to-source optimizer for 
the HPF programming language. The system will use the generalized 
source-to-source transformation system developed in task 3.2, together
with a data-base of optimizing source-to-source transformations.

The purpose of this task is to identify source-to-source optimizations
that optimize HPF code, and to create a basic source to-source
optimizer implementing them.  The main outputs will thus be a source
optimizer for HPF, and feedback to task 3.2 in the form of a list of
requirements concerning the kind of pattern-matching capabilities and
program transformations needed by such an optimizer.

We will investigate all program transformations that can be applied to HPF
programs---not only those specific to the extensions of HPF over Fortran 90.

We will also investigate complicated optimizations that cannot usually be found
by an automatic tool, but which are often found by users.
A common example is the replacement of some typical small program kernels
by optimized (probably very different) equivalent program kernels.
The characteristics of the generalized source-to-source transformation system
developed in task 3.2 allows one to implement these kind of transformations
easily and incrementally, and so makes them practical.

The work will consist of two parts:
\bi
	\item To investigate source-to-source transformations that can
optimize HPF code.

	\item To implement those transformations in the data-base, and to 
test and benchmark them.
\ei
The output source-to-source optimizer {\em could
be used in any HPF programming environment}.

Strong points of such a system are that it could be easily
expanded as new optimizing transformations are found, and that the user
will be able to build his own data-base of optimizing transformations.
% }}}
% {{{  \subsubsection*{Task 3.4: HPF intermediate code optimiser} -- ok
\subsubsection*{Task 3.4: HPF intermediate code optimiser}

Several of the HPF compilers currently being implemented work
by translating the HPF source into Fortran 90 plus calls to a standard 
message-passing library.  PVM and MPI are those most commonly proposed.

The code produced by these compilers is unlikely to be optimal.
That applies especially to initial implementations,
but is likely to remain the case.  Even for sequential 
languages, sophisticated users can write assembler code that is more 
efficient than that produced by the compiler.

This opens the door to a new method of optimizing HPF programs:
modification of the intermediate code produced by the translator.

In this task, this scheme will be implemented within the HPF programming 
environment currently being developed by BES.  This programming environment
consists of a translator from HPF to Fortran 90 plus PVM or MPI, a
source-level debugger and a profiler.

The following work will be performed:
\be
	\item The existing source-level debugger and the profiler
will be extended and integrated to produce a new tool.
This tool will
allow the user to examine the original HPF program along with the code
produced by the translator, and the profiling information produced by the
profiling system.
   
	\item The translator will be modified to allow the user to 
replace or modify the code that it generates.
\ee

The tool will, for example, allow the user to step with the debugger through
the program.  In addition to seeing the original source code of 
the program being executed, the user will also be able to see
the translated code with message-passing calls,
what communications are taking place, and 
the cost of them.   To optimize the program the user might then:
\be
	\item Modify the original code so as to remove some of the
communications.  (A problem encountered by users of
Connection Machine Fortran, for example, is that seemingly innocent statements 
have a lot of communication associated with them.)

	\item Provide alternative code to that created by the translator.  
(The translator will be modified to allow the user to do this).  This is 
similar to the technique of inserting assembler code in programs written 
in a high-level language.  This technique should generally be used 
with care as it impairs portability, but it is sometimes very useful, as it
allows dramatic optimizations of some program kernels.
\ee

{\em This work will be done in a way that makes it as portable as possible 
to other HPF compilers that are implemented as translators to Fortran 90 with 
message-passing}.  The tool will also be integrated with the common 
tool interface developed in tasks 1.5 and 1.6.

The HPF programming environment used as a baseline for this task is
currently being implemented in another (Eureka) project.  It will not 
be completed until the second half of 1994, so this task will therefore
start in the second year of this project.
% }}}


% {{{  *** rejected figure ***
% \begin{figure}
% \begin{center}
% \setlength{\unitlength}{\baselineskip}
% \begin{picture}(12,6)
% 
% \put(6,5.5){\makebox(0,0){HPF}}
% 
% \put(6,5){\vector(0,-1){1}}
% 
% \put(6,3.5){\makebox(0,0){`optimised' HPF}}
% 
% \put(6,3){\vector(0,-1){1}}
% 
% \put(6,1){\makebox(0,0){\shortstack{`optimised' \\ Fortran + message-passing}}}
% 
% \end{picture}
% \caption{Transforming HPF into `otpimised' message-passing code \label{duval-pic2}}
% \end{center}
% \end{figure}
% }}}
% }}}
\newpage

% {{{  \subsection{Workpackage 4: Validation and evaluation} -- OK
\subsection{Workpackage 4: Validation and evaluation}

% {{{  intro 

While tool and library developers will obviously perform their own
validation and evaluation as an integral part of the development,
it is useful to have a task to evaluate the tools independently.
This role will be undertaken by Telmat, who are `independent' in the 
sense of not being involved themselves in tool development in the 
project, but who have a strong interest in using the the tools both as
software support for their hardware products and for `in house' porting 
of customers' applications.  They are also well suited to this role because 
of their wide experience and constant tracking of commercially available
programming environments and support tools, and their knowledge of users' 
demands and expectations.

The evaluation will be performed using a variety of source codes, including:
\bi
	\item real application codes, including large geoscience 
applications (e.g.\ seismic modelling),
	\item `Genesis' benchmarks,
	\item `EuroBen' benchmarks,
\ei
on variety of hardware platforms, namely:
\bi
	\item CS-2,
	\item 88000 based workstation cluster,
	\item Future TELMAT MPP machines.
\ei

The workpackage comprises two tasks.

% }}}

% {{{  \subsubsection*{Task 4.1: Ports to HPF}
\subsubsection*{Task 4.1: Ports to HPF}

The first tools developed in the project will not be available for evaluation
until after the first year of the project.  However, this time will be 
usefully occupied by (i) testing the ideas for code restructuring and
`improvement' upon which the tools are based, by hand transforming
codes and measuring the effects on performance, and (ii) evaluating existing
and forthcoming HPF technology and support tools for comparison with
the planned project developments.  This will provide valuable feedback 
to the tool development.  The task will use currently available tools 
(e.g.\ Foresys, Forest and Partita from \Connexite) and `HPF' compiler/
translator technology (e.g. XHPF77 \& HPF77) together with others 
that may become available.

The output of this task will be a deliverable report on:
\bi
	\item the performance, using current HPF compilers / translators, 
of codes `naively' ported to HPF;
	\item the performance gains achieved by various code modifications;
	\item guidelines for an efficient HPF programming style.
\ei
This will provide feedback to the tool development.
% }}}
% {{{  \subsubsection*{Task 4.2: Evaluation of tools}
\subsubsection*{Task 4.2: Evaluation of tools}

In this task the project tools will be evaluated as they become available,
and the comparative evaluation of HPF support software from other sources 
will also be continued.

Activities will include:
\bi
	\item Using the tools within Telmat's activities in other 
European projects, notably to port industrial application codes to 
MPP systems, where the tools will provide MPP programming support.

	\item Promoting good HPF programming styles through training 
using the tools, e.g.\ via the COMETT ACT project.

	\item Releasing early versions of selected project software 
(under non-disclosure agreements) to selected customers for independent 
feedback.
\ei

Telmat have a strong interest in exploiting the tools for use
on the hardware platforms they market.
% }}}
% }}}
\newpage

% {{{  \subsection{Workpackage 5: Project management} -- OK - very short
\subsection{Workpackage 5: Project management}

The project management details are described in the next section.
% }}}

% {{{  \subsection{Risks} -- OK
\subsection{Risks}

Part of the work on the HPF programming environment that will be an
input to task 3.4 (`HPF intermediate code optimiser') depends on 
funding from a proposed Eureka project, whose funding status will be 
resolved on June 93. In the (unlikely) event that the 
Eureka funding fails the work for task 3.4 may have to be delayed or 
cancelled.  Should this happen, it should not have serious repercussions 
for the rest of the project, as this task does not produce outputs
to any other task; it only has inputs from them.
% }}}
\newpage

% }}}

% {{{  8. Project Management -- ok
\section{Project Management}

The University of Southampton will be the Coordinating Contractor 
for the project, and will manage the project via its Parallel Applications 
Centre (PAC).

The PAC staff have considerable expertise in managing major industrial
and defense-related R \& D projects.  The PAC is currently responsible 
for managing collaborative HPC applications projects with numerous 
companies, including BP International, British Gas, Cambridge Control, 
Ordnance Survey, Rover and Scott Wilson Kirkpatrick.  Since this project 
brings together several commercial organisations, PAC's neutrality is an 
advantage in the role of project manager.  It also has considerable 
expertise and background in the field of parallel high performance computing.

We will appoint a Project Manager to be responsible for 
management and coordination of the project. He will be supported by an 
administrative assistant.

The responsibilities of the Project Manager and administrator are:
% {{{  PM responsibilities
\be
	\item to coordinate all activities within the project, and to 
ensure that any deviations are resolved (involving the project's Management 
Board as necessary);

	\item to liaise between the project and the Commission on all 
matters concerning the project;

	\item to organise regular technical and administrative meetings, 
presentations, exhibitions etc. as appropriate;

	\item to coordinate the preparation and distribution of all reports;

	\item to maintain accurate records of cost and effort reports;

	\item to act as project representative for liaison with other projects.
\ee
% }}}

The project's Management Board will consist of one person appointed by each
of the partners, under the chairmanship of the Project Manager. This appointee
will have authority to make both technical and administrative decisions on
behalf of the respective partner. A deputy of similar responsibility may 
replace an appointee unable to attend a meeting, in order to ensure all 
contractors can be represented. Each appointee will also represent the 
interests of the Associated partners and sub-contractors who are directly 
or indirectly connected with that partner. A partner's representative may 
be replaced at any time by written notice to all other partners. 
A partner's representative on the Management Board will hold one vote when 
decisions are made.

Meetings of the Management Board will be held either immediately before or
immediately after other project meetings, and will be called at the request of
the Project Manager or any of the partner's representatives. There will be at
least seven days notice of such meetings, with an agenda to be circulated by
the project administrative assistant. Meetings can be called at shorter 
notice if the Project Manager deems the need to be extremely urgent. 

The Management Board shall be responsible for:
% {{{  MB responsibility
\be
	\item Decisions on all project management issues. A simple 
majority decision will carry a motion. A tied vote will result in a 
motion not being carried.

	\item Amendments to the workplan as defined in the Technical Annex, 
and resolution of disputes between partners that do not affect their legal
rights and obligations. A simple majority decision will carry a motion.
A tied vote will result in a motion not being carried.

	\item The terms of the CEC contract, the costs or time schedules 
described in that contract, the termination date of the contract and the 
procedure for publications and press releases. Decisions on all of these 
matters must be decided by unanimous vote of all partners.

\ee
% }}}

The main responsibility of the Management Board is to monitor the progress
of each task with respect to the overall workplan to ensure timely achievement
of deliverables and to identify all problems at an early stage.

Each workpackage has a lead contractor, who is responsible for coordinating
the collaboration within the workpackage.

The quality control will be ensured by the Management Board. In particular
all deliverables within the project must be agreed by the Management Board
before presented to the CEC.


\newpage
% }}}
% {{{  9. Workpackages -- ok
\section{Workpackages}

% {{{  \subsection{Workpackage 1: HPF program development tools} -- ok
\subsection{Workpackage 1: HPF program development tools}

\begin{wptab}
\bf Leader:                 &       \Connexite              \\
\bf Other partners:         &       BES SA, INRIA, University of Southampton      \\
\bf Duration:               &       3 years                 \\    \hline
\bf Manpower:                                   \\
Univ.\ Southampton      &       3 MY                    \\
        \taskdesc{1.1}{A tool for improving `dusty deck' Fortran codes: 1 MY ($1+0+0$)} \\
        \taskdesc{1.2}{Data mapping `assistant': 2 MY ($0+1+1$)}        \\
BES SA                  &       1.5 MY                  \\
        \taskdesc{1.3}{Intrinsics and library call generator: 1.5 MY ($.5+.5+.5$)} \\
\Connexite              &       4.5 MY                  \\
        \taskdesc{1.4}{Adapting Forsys tools for HPF: 1.5 MY ($1 + .5 + 0$)} \\
        \taskdesc{1.5}{Building modern interfaces for tools: 1.5 MY ($0 + .5 + 1$)}        \\
        \taskdesc{1.6}{Inter-tool protocol: 1.5 MY ($0 + 1 + .5$)} \\
INRIA			&	3 MY			\\
        \taskdesc{1.5}{Building modern interfaces for tools: 1.5 MY ($0 + .5 + 1$)}        \\
        \taskdesc{1.6}{Inter-tool protocol: 1.5 MY ($1 + .5 + 0$)} \\
        &                                               \\
Total                   &       12 MY                   \\      \hline
\makebox[0ex][l]{{\bf Other major resources required:}~~~~~None}    \\ \hline
\end{wptab}
% }}}
% {{{  \subsection{Workpackage 2: HPF performance monitoring and visualisation}
\subsection{Workpackage 2: HPF Visualisation and Graphics}

\begin{wptab}
\bf Leader:                 &       Siemens                 \\
\bf Other partners:         &       IBM Bergen, University of Southampton, TUM  \\
\bf Duration:               &       3 years                 \\      \hline
\bf Manpower:                                   \\
TUM                     &       3 MY \\
  \taskdesc{2.1}{Trace and cross-reference data: 3 MY ($1 + 1 + 1$)} \\
Univ.\ Southampton      &       3 MY \\
  \taskdesc{2.2}{Array-level visualisation tool: 3 MY ($1 + 1 + 1$)} \\
Siemens                 &       9 MY \\
  \taskdesc{2.3}{Message-passing level visualisation tool: 9 MY ($3 + 3 + 3$)} \\
IBM Bergen              &       6 MY                    \\
  \taskdesc{2.4}{HPF Graphics Library: 6 MY ($2 + 2 + 2$)} \\
Total                   &       21 MY                   \\      \hline
\makebox[0ex][l]{{\bf Other major resources required:}~~~~~None}    \\ \hline
\end{wptab}


% }}}
% {{{  \subsection{Workpackage 3: HPF optimisation}
\subsection{Workpackage 3: HPF optimisation}

\begin{wptab}
\bf Leader:                 & BES SA                        \\
\bf Other partners:         & University of Southampton     \\
\bf Duration:               &       3 years                 \\      \hline
\bf Manpower:                                   \\
Univ. Southampton       &       3 MY                    \\
        \taskdesc{3.1}{HPF translation schemes: 3 MY ($1+1+1$)}         \\
BES SA                  &       6.5 MY                  \\
        \taskdesc{3.2}{Source-to-source transformation system: 3 MY ($1+1+1$)} \\
        \taskdesc{3.3}{Source-to-source optimiser: 1.5 MY ($0.5+0.5+0.5$)} \\
        \taskdesc{3.4}{HPF intermediate code optimiser: 2 MY ($0+1+1$)} \\
        &                                               \\
Total                   &       9.5 MY                  \\      \hline
\makebox[0ex][l]{{\bf Other major resources required:}~~~~~None}    \\ \hline
\end{wptab}

% }}}
% {{{  \subsection{Workpackage 4: Validation and evaluation}
\subsection{Workpackage 4: Validation and evaluation}

\begin{wptab}
\bf Leader:                 &       Telmat Informatique     \\
\bf Other partners:         &       -                       \\
\bf Duration:               &       3 years                 \\      \hline
\bf Manpower:                                   \\
Telmat                  &       3 MY                    \\
\taskdesc{4.1}{Evaluation of project tools: 3 MY ($1 + 1 + 1$)} \\
        &                                               \\
Total                   &       3 MY                    \\      \hline
\makebox[0ex][l]{{\bf Other major resources required:}~~~~~None}    \\ \hline
\end{wptab}
% }}}
% {{{  \subsection{Workpackage 5: Project Management}
\subsection{Workpackage 5: Project Management}

\begin{wptab}
\bf Leader:                 &       University of Southampton \\
\bf Other partners:         &       -                       \\
\bf Duration:               &       3 years                 \\      \hline
\bf Manpower:                                   \\
Univ. Southampton                       &       3 MY                  \\
\taskdesc{5.1}{Project Management: 3 MY ($1 + 1 + 1$)} \\
        &                                               \\
Total                   &       3 MY                  \\      \hline
\makebox[0ex][l]{{\bf Other major resources required:}~~~~~None}    \\ \hline
\end{wptab}
% }}}

\newpage
% }}}
% {{{  10. Workpackage interdependencies and milestones -- ok
\section{Workpackage interdependencies and milestones}

\vspace{2\baselineskip}

See attached Pert and Gantt charts.

\newpage

% all ``eps'' files to be copied from `dbc/docs/hpf/hpf-toolkit/proposal'.

\centerline{\psfig{figure=figs/gantt_1.eps,height=\textheight}}
\centerline{\psfig{figure=figs/gantt_2.eps,height=\textheight}}
\centerline{\psfig{figure=figs/gantt_3.eps,height=\textheight}}
\centerline{\psfig{figure=figs/gantt_4.eps,height=\textheight}}
\centerline{\psfig{figure=figs/gantt_5.eps,height=\textheight}}
\centerline{\psfig{figure=figs/gantt_6.eps,height=\textheight}}
\centerline{\psfig{figure=figs/pert.eps,width=\textwidth}}

% Last one could do with centering on the page, somehow.
\newpage
% }}}
% {{{  11. Major Deliverables and Review Points -- ok
\section{Major Deliverables and Review Points}

\newlength{\deliverable}
\settowidth{\deliverable}{Defn: trace format, X-ref, interfaces}
\renewcommand{\arraystretch}{1.2}

% {{{  \subsection{Workpackage 1}
\subsection{Workpackage 1}

%\begin{tabular}{|c|l|l|l|c|c|}          \hline
\begin{tabular}{|c|p{\deliverable}|l|l|c|c|}          \hline
Task    & Deliverable                           & Id	& type		& avail-	& Months from   \\
        &                                       &	&               & ability	& project start \\ \hline
\multicolumn{6}{|l|}{\it 1.1: Interprocedural normalisation}						\\ \hline
        & Interprocedural normalisation tool    & 1.1a	& report	& P             & 12		\\
        &                                       & 1.1b	& tool		& R             & 12		\\ \hline
%
\multicolumn{6}{|l|}{\it 1.2: Data mapping `assistant'}							\\ \hline
        & Alignment generator                   & 1.2a	& report	& P             & 24    	\\
        &                                       & 1.2b	& tool		& R             & 24    	\\
        & Data mapping `assistant'              & 1.2c	& report	& P             & 36    	\\
        &                                       & 1.2d	& tool		& R             & 36    	\\ \hline
%
\multicolumn{6}{|l|}{\it 1.3: Intrinsics / library call generator (ILG)}                    		\\ \hline
	& ILG progress report                   & 1.3a	& report	& P             & 12		\\
        & HPF intrinsics data-base	        & 1.3b	& tool		& C             & 12		\\
	& ILG progress report                   & 1.3c	& report	& P             & 24		\\
        & HPF library data-base                 & 1.3d	& tool		& C             & 24		\\
        & ILG final report			& 1.3e	& report	& P             & 36		\\
        & HPF num-library data-base             & 1.3f	& tool		& C             & 36		\\ \hline
%
\multicolumn{6}{|l|}{\it 1.4: Adapting Foresys Tools for HPF}                               		\\ \hline
        & adapting parser, visualizer, Forest   & 1.4a	& code		& C             & 6		\\
        & product Foresys/HPF                   & 1.4b	& code		& C             & 18		\\ \hline
%
\multicolumn{6}{|l|}{\it 1.5 Building Modern Interfaces for Tools}                          		\\ \hline
\multicolumn{6}{|l|}{~~~1.5.1 Source Manipulation Tools}                                		\\ \hline
        & prototype environment w/src tools	& 1.5a	& code		& R		& 24		\\
        & documentation source tools interface  & 1.5b	& report	& P		& 36		\\ \hline
\multicolumn{6}{|l|}{~~~1.5.2 Run Time Tools}                                           		\\ \hline
\multicolumn{6}{|l|}{~~~1.5.3 Integration and Packaging}                                		\\ \hline
        & doc final HPF environment 		& 1.5c	& report	& P             & 36		\\
        & product final HPF environment     	& 1.5d	& code		& C             & 36		\\ \hline
%
\multicolumn{6}{|l|}{\it 1.6 Inter-tool Protocol}                                           		\\ \hline
\multicolumn{6}{|l|}{~~~1.6.1 Defining the communication protocol}                      		\\ \hline
        & protocol specification                & 1.6a	& report	& P		& 12		\\ \hline
\multicolumn{6}{|l|}{~~~1.6.2 Sophtalk implementation of the protocol}                  		\\ \hline
        & product w/existing tools              & 1.6b	& code		& R		& 18		\\ \hline
\multicolumn{6}{|l|}{~~~1.6.3 Chosen standard implementation of the protocol}           		\\ \hline
        & doc standard version                  & 1.6c	& report	& P		& 24		\\
        & product using standard                & 1.6d	& code		& C		& 36		\\ \hline
\end{tabular}
% }}}
\newpage

% {{{  \subsection{Workpackage 2}
\subsection{Workpackage 2}

%\begin{tabular}{|c|l|l|l|c|c|}          \hline
\begin{tabular}{|c|p{\deliverable}|l|l|c|c|}          \hline
Task    & Deliverable                           	& Id	& type		& avail-	& Months from	\\
        &                                       	&	&		& ability	& project start	\\ \hline
\multicolumn{6}{|l|}{\it 2.1: Trace and cross reference data}							\\ \hline
	& Defn: trace format, X-ref, interfaces		& 2.1a	& report	& P		& 12		\\
	& Impln: generation \& reading funcs		& 2.1b	& code		& P		& 18		\\
	& Compression of traces and X-refs		& 2.1c	& report	& P		& 24		\\
	&                                  		& 2.1d	& code		& P		& 30		\\
	& Evaluation					& 2.1e	& report	& P		& 36		\\ \hline
%
\multicolumn{6}{|l|}{\it 2.2: Array-level visualisation tool}  \\ \hline
	& Visualisation tool design			& 2.2a	& report	& P		& 6		\\
	& Prototype implementation			& 2.2b	& code		& R		& 18		\\
	& Instrumented subset compiler 			& 2.2c	& code		& R		& 24		\\
	& Final implementation				& 2.2d	& code		& R		& 36		\\
	& Evaluation					& 2.2e	& report	& R		& 36		\\ \hline
%
\multicolumn{6}{|l|}{\it 2.3: Message-passing level visualisation tool} \\ \hline
	& Visualization of PVM/MPI level		& 2.3a	& tool		& R		& 12		\\
	& HPF execution visualization			& 2.3b	& report	& P		& 24		\\
	& Prototype             			& 2.3c	& tool		& R		& 24		\\
	& HPF execution visualization tool		& 2.3d	& tool		& R		& 30		\\
	& Evaluation             			& 2.3e	& report	& P		& 36		\\ \hline
%
\multicolumn{6}{|l|}{\it 2.4: HPF Graphics Library} \\ \hline
	& Requirements definition document		& 2.4a	& report	& P		& 6		\\
	& First prototype				& 2.4b	& code		& P		& 12		\\
	& User documentation				& 2.4c	& report	& P		& 12		\\
	& Progress report				& 2.4d	& report	& P		& 24		\\
	& Final report					& 2.4e	& report	& P		& 36		\\ \hline
\end{tabular}

% }}}
\newpage

% {{{  \subsection{Workpackage 3}
\subsection{Workpackage 3}

%\begin{tabular}{|c|l|l|l|c|c|}          \hline
\begin{tabular}{|c|p{\deliverable}|l|l|c|c|}          \hline
Task    & Deliverable                           	& Id	& type          & avail-	& Months from   \\
        &                                       	&       &               & ability	& project start \\ \hline
\multicolumn{6}{|l|}{\it 3.1: Translation Schemes}									\\ \hline
	& Literature survey				& 3.1a	& report	& P		& 3		\\
	& Calculation placement strategies		& 3.1b	& report	& P		& 12		\\
	& Progress report				& 3.1c	& report	& P		& 24		\\
	& Testbed implementation and final report	& 3.1d & tool		& R		& 36		\\ \hline
\multicolumn{6}{|l|}{\it 3.2: Source-to-source transformation system}						\\ \hline
        & progress report                       	& 3.2a	& report	& P             & 12    	\\
        & batch system                          	& 3.2b	& tool          & C             & 12    	\\
        & progress report                       	& 3.2c	& report        & P             & 24    	\\
        & interactive                           	& 3.2d	& tool          & C             & 24    	\\
        & final report					& 3.2e	& report        & P             & 36    	\\
        & optimised                             	& 3.2f	& tool          & C             & 36    	\\ \hline
\multicolumn{6}{|l|}{\it 3.3: Source-to-source optimiser}                                   			\\ \hline
        & progress report                       	& 3.3a	& report        & P             & 12    	\\
        & prototype data-base                   	& 3.3b	& tool          & C             & 12    	\\
        & progress report                       	& 3.3c	& report        & P             & 24    	\\
        & final report					& 3.3d	& report        & P             & 36    	\\
        & data-base                             	& 3.3e	& tool          & C             & 36    	\\ \hline
\multicolumn{6}{|l|}{\it 3.4: HPF intermediate code optimiser}                             				\\ \hline
        & progress report                       	& 3.4a	& report        & P             & 24    	\\
        & prototype                             	& 3.4b	& tool          & C             & 24    	\\
        & final report                       		& 3.4c	& report        & P             & 36    	\\
        & tool                                  	& 3.4d	& tool          & C             & 36    	\\ \hline
\end{tabular}

% }}}
% {{{  \subsection{Workpackage 4}
\subsection{Workpackage 4}

%\begin{tabular}{|c|l|l|l|c|c|}          \hline
\begin{tabular}{|c|p{\deliverable}|l|l|c|c|}          \hline
Task    & Deliverable                           & Id	& type          & avail-	& Months from   \\
        &                                       &	&               & ability	& project start \\ \hline
\multicolumn{6}{|l|}{\it 4.1: Ports to HPF}									\\ \hline
	& Progress report			& 4.1a	& report	& P		& 12		\\ \hline
\multicolumn{6}{|l|}{\it 4.2: Evaluation of project tools}							\\ \hline
	& Final report				& 4.2a	& report	& P		& 36		\\ \hline
\end{tabular}

% }}}
% {{{  \subsection{Workpackage 5}
\subsection{Workpackage 5}

%\begin{tabular}{|c|l|l|l|c|c|}          \hline
\begin{tabular}{|c|p{\deliverable}|l|l|c|c|}          \hline
Task    & Deliverable                           & Id	& type          & avail-	& Months from   \\
        &                                       &	&               & ability	& project start \\ \hline
\multicolumn{6}{|l|}{5.1: Project Management}								\\
\hline
\end{tabular}
% }}}
\renewcommand{\arraystretch}{1}

\newpage
% }}}
% {{{  12. Other dependencies -- ok
\section{Other dependencies}


Part of the work by BES on the HPF programming environment that will be an
input to task 3.4 (`HPF intermediate code optimiser') depends on 
funding from a proposed Eureka project, whose funding status will be 
resolved on June 93. In the (unlikely) event that the 
Eureka funding fails the work for task 3.4 may have to be delayed or 
cancelled.  Should this happen, it should not have serious repercussions 
for the rest of the project, as this task does not produce outputs
to any other task; it only has inputs from them.

\newpage
% }}}

% {{{  refs *****
\begin{thebibliography}{99}

\bibitem[EA88]{Eichholz88}
S.~Eichholz and F.~Abstreiter.
\newblock Runtime observation of parallel programs.
\newblock In {\em Proceedings of the Conference of Parallel Processing
  (CONPAR'88)}, Manchester (UK), September 1988. Cambridge University Press.

\bibitem[Eic87]{Eichholz87}
S.~Eichholz.
\newblock Parallel programming with {ParMod}.
\newblock In S.~K. Sahni, editor, {\em Proceedings of the 1987 International
  Conference on Parallel Processing}, pages 377--380, University Park, August
  1987. The Pennsylvania State University Press.

\bibitem[Fri92]{Friedrich92}
M.~Friedrich.
\newblock {\em {Sprachmittel und Werkzeuge zur Unterst\"utzung paralleler und
  verteilter Programme}}.
\newblock {Dissertation, SFB--Bericht}, Institut f\"ur Informatik, TU
  M\"unchen, March 1992.

% \bibitem[Hea90]{Heath90}
% M.~T.~Heath.
% \newblock Visual animation of parallel algorithms for matrix computations.
% \newblock In {\em 5th Distributed Memory Computing Conference},
%  pages 1213--1222, Charleston, South Carolina, U.S.A., 1990.

\bibitem[IW93]{IlmWie93}
H.~Ilmberger, C.P.~Wiedemann.
A Visualization and Control Environment for Parallel Program Debugging.
HICSS-26 (Hawaii Int.\ Conf.\ on System Sciences, Jan. 93, Hawaii), Vol.\ II, 
387-396.

\bibitem[WSF91]{Weininger91}
A.~Weininger, T.~Schnekenburger, and M.~Friedrich.
\newblock Parallel and distributed programming with {ParMod-C}.
\newblock In {\em First International Conference of the Austrian Center for
  Parallel Computation (ACPC'91)}, Salzburg, Austria, 1991.

\bibitem[Mer91]{adapt}
J.H.~Merlin.
ADAPTing Fortran~90 array programs for distributed memory architectures.
{\em Proc.\ 1st Int.\ Conf.\ of the ACPC\/}, Salzburg, Sept.\ 1991.

\bibitem[Mer92]{adapt-tech}
J.H.~Merlin.
Techniques for the Automatic Parallelisation of `Distributed Fortran~90'.
Southampton University technical report, SNARC 92-02, 1992.

\end{thebibliography}
% }}}

\end{document}

% {{{  manpower estimate
Manpower estimate
-----------------

WP1: HPF development tools
WP2: perf monitoring and visualisation
WP3: optimisation
WP4: libraries
WP5: evaluation

Updated: 7/4/93

		| total	|| WP1	| WP2	| WP3	| WP4	| WP5	|
----------------|-------||------|-------|-------|-------|-------|-------
BES (Barcelona)	| 8	|| 1.5	| 	| 6.5	|	|	|
Connexity	| 7.5	|| 7.5	|	|	|	| 	|
IBM Bergen	| (6)	||	|	|	| (6)	|	|
INRIA		|	||	|	|	|	|	|
Siemens		| 9	||	| 9	|	|	|	|
Soton		| 9	|| 3	| 3	| 3	|	|	|
Telmat		| 3	||	|	|	|	| 3	|
  TUM		| 3	||	| 3	|	|	|	|
		|	||	|	|	|	|	|
Management	| 3	||	|	|	|	|	| 3
----------------|-------||------|-------|-------|-------|-------|-------
		| 42.5	|| 12	| 15	| 9.5	| (6)	| 3?	| 3
		| (48.5)||

% }}}

% {{{  REMOVED STUFF
% {{{  Telmat
Supposed to be 'project description'!

% {{{  added words 1
\added{The permanent dependency on the development software tools developed 
outside Europe, particularly in the US, has created a lack of confidence 
in the European inustry being able to deliver any usefull technology for 
the porting of industrtial applications on parallel systems. The existence 
of industrial level tools and providers in Europe is crucial for the 
European system manufacturers inustry, because of the permanent exchange 
and feedback which is needed for the design of parallel systems.

John, please expand on that material.}
% }}}

\vspace{2\baselineskip}

% {{{  added words 2
\added{Suggests WP title is `Validation and Evaluation'.

\subsection*{Evaluation}

Due to the strong interest in the new HPF standard worldwide, part of the 
tools which are being designed in this project are due to apear at 
different points over the next three years. There will then be a need to 
evaluate them, and then to compare them with the tools being designed. 
This task will provide important feedback to the design tasks, allowing 
minor modifications and improvements.

This task will not create any new benchmarking suite, but will concentrate 
on finding the suitable ones for evaluating :
\bi
	\item translation of F77 codes to HPF.
	\item optimisation of HPF codes.
	\item visulalisation of run-time profiling information.
\ei

Outputs :
\bi
	\item End of Year 1 : Evaluation Report 1
	\item End of Year 2 : Evaluation Report 2
\ei
Deliverables :
\bi
	\item End of Year 3 : Global evaluation report
\ei


\subsection*{Validation}

The main objective of this validation task will be to progressively take 
the tools coming from the development tasks and run them with available 
vaidation suites.

Project manager, please align the following Outputs with the deliverables 
on tools :
\bi
	\item Ouput Validation 1 : Report on validation of the tools
	\item Deliverable Validatiobn : overall validation report
\ei
\mbox{}}
% }}}


[FROM TELMAT (19/4/93)\ldots -- basically 'baseline' & exploitation.]
Telmat, as  member of PCI, is a manufacturer and a vendor of high 
performance computers based on MPP technology for the scientific and 
industrial computing market.

Telmat recognizes the importance of working together with industrial users 
of MP in order to open the market for its products. Telmat welcomes the 
present orientation of the Esprit Workprogram towards that type of user 
driven cooperaative projects.

The availability of well written parallelized codes is paramount for the 
success of MPP systems on the industrial market in the next three to 
five years. Such applications can either be existing codes or new codes 
based on algorithms that could hardly be implemented on traditional 
machines due to the large computing power they generate.

The key to the success of the overall industrial applications port on 
MPPs is the portability issue. It is very important that standards will 
be defined and supported very quickly in order to create the right minds' 
comfort of industrial end-users. In particular, codes should be easily 
portable from different machine of the same generation, but also more 
than that, it is essential to be able to maintain the investment between 
different generations of machines. It is also very important to be able 
to translate old codes written in Fortran 66 or Fortran 77 to the new 
Fortran 90 (+communications libraries) or HPF. Due to the enormous amount 
of codes already existing, this operation has to be automatised or at 
least interactively managed. The lack of availability of industrial codes 
on parallel systems has in large part to do with this unvailability of 
reengineering tools. We intend to commercialise these tools and to promote 
their use in our installed base, but also in the Esprit projects where we 
are alredy invlved or will be involved in this call.

% }}}
% {{{  Connexite
(from summary)

It will also import a technology for building programming
environments developed in an earlier Esprit project (GIPE II)
and develop an open architecture that allows easy interoperability of
new tools as they arrive on the market. While all tools will be
operable in batch mode, a separable interface toolkit will give
access to all functionalities in a uniform manner.

% }}}

% {{{  Siemens

% }}}
% {{{  TUM

% }}}

% {{{  BES

% }}}

% {{{  IBM
[FROM IBM (16/4/93)\ldots] -- from summary

An obstacle in distributed memory parallel programming, in general, 
is run-time graphics. This is because presently most parallel environments
do not have graphics explicitly written for shared memory computers.
(exception: Express has PLOTIX). Working around this by collecting the data in
one computer can be very time consuming and memory demanding. 
We propose to build a library callable from HPF that will display
the data in any particular or all processors. The library will contain
color graphics for 1-d, 2-d, and 3-d.
(too long and almost recap of next section)

% }}}

% {{{  Soton

% }}}


% {{{  \section{Project Objectives} -- old
\section{Project Objectives} -- old

The principal objectives of the project are as follows:
\be
% {{{  \item To develop tools to assist the conversion of standard

	\item To develop tools to assist the conversion of standard
Fortran programs to HPF.

[FROM BES\ldots]
One such tool is an Intrinsics/library generator.
HPF contains an extensive set of intrinsic and library procedures.
The objective of this tool is to recognize code in Fortran programs
that can be replaced by these procedures and to automatically perform the
replacement. This will thus help in the migration of existing Fortran 
applications to HPF.
% }}}
% {{{  \item To develop performance monitoring and visualisation tools 

	\item To develop performance monitoring and visualisation tools 
for HPF programs.

[FROM SIEMENS\ldots]
The users' acceptance of any informal standard like HPF is strongly
enhanced by an adequate programming environment.  Since HPF will be available
on a wide variety of DM-MIMD architectures, portable, system-independent
tools are necessary for the analysis of the program behaviour. Todays
visualisers are mostly too system-oriented and apart from exceptions
like Paragraph not portable. Moreover they do not provide support for both
data-oriented and execution driven views as we intend. These views are
vital to get an integrated picture of the runtime behaviour
and its potential for optimisation.

[FROM TUM\ldots]
One important step to get system-independent tools is the definition of
common trace formats for different trace producing and trace consuming tools.


[TUM -- NEW STUFF\ldots]
common trace formats (and semantics) => basis for adapting existing tools
for the HPF environment + reusage of HPF tools in other environments 
task 2.1 (trace and cross-referebce data for HPF visualisation) will try 
to prepare the way to common trace format standards 


% }}}
% {{{  \item To develop HPF optimisation techniques.

	\item To develop HPF optimisation techniques.

A tool to allow the user optimization of the intermediate code produced
by HPF programming environments that perform source-to-source translation
will be developed. This tool will allow the detailed investigation of the
code produced by those programming environments.
% }}}
% {{{  \item To develop an HPF graphical library.

	\item To develop an HPF graphical library.

[FROM IBM (16/4/93)\ldots]
Development of an efficient graphical library for run-time use.
The library contains basic functions for 1-d, 2-d and 3-d visualization
with the colors and resolution expected of todays graphics. The routines
will be optimal for DM-MIMD computers where the data is assumed to be 
distributed among several processors.


[IBM - NEW STUFF\ldots]
The current 'state of the art' in run-time parallel Distributed Memory 
graphics is the 2-d Library of Parasoft. This is not good enough for the
needs of todays large 3-d models where in some cases the model can not
fit on a single computer. The advance of the state of the art is to produce
an easy-to-use advanced 3-d run-time graphics library that will be callable
from High Performance Fortran.


% }}}
% {{{  \item To build an open ended programming environment in which separately

	\item \mbox{} [FROM CONNEXITE---Gilles Kahn\ldots]
To build an open ended programming environment in which separately 
designed tools can cooperate, and a modern client/server man-machine 
interface gives a uniform and intuitive access to the system's functionalities.
The resulting environment will bring unprecedented support to the 
task of building HPF scientific software.

% }}}
% {{{  \item To test and evaluate this software.

	\item To test and evaluate this software.
% }}}
\ee

\newpage
% }}}
% {{{  \section{Project Contribution to Esprit Aims and Objectives} -- old
\section{Project Contribution to Esprit Aims and Objectives} -- old

This project addresses the `Basic High Performance Computing (HPC)
tools and technologies' sub-domain of the Esprit Work Programme for 1993-4,
and in particular task 3.5 (or 3.6?).  The objectives of this sub-domain 
are described as:
\begin{quote}
	To improve and consolidate the environment in which software and 
applications for HPCN systems are developed, \ldots
\end{quote}
[FROM BES\ldots] The HPF intermediate code optimiser, intrinsic/library 
call generator and source to
source optimizer are addressed specifically to this aims. The last two tools
will improve and consolidate all programming environments for HPF. The first
will improve and consolidate programming environments that depend on a
translator.

\begin{quote}
	\ldots to encourage standardisation and common practices 
amongst a widespread group of vendors and users.
\end{quote}
[FROM BES\ldots] The creation of tools for HPF encourages its widespread 
use and so its standardization.

\begin{quote}
	Architecture-independent programming, ease of programming, general purpose, 
and predictable high level of performance will be the main focus.
\end{quote}
[FROM BES\ldots] The three tools we (BES) will develop address mainly the 
high-level of performance (optimization) issues.

\begin{quote}
	To provide generic software which eases the use of a wide range of applications.

To continue to stimulate the development of next generation HPCN hardware
and software in accordance with user requirements.
\end{quote}

The aims of task 3.5 specifically are:
\begin{quote}
	Development of methodology, associated software tools and supporting standards
which will rationalise the development of software for parallel systems and 
satisfy the production requirements of commercial and technical applications.
\end{quote}
[FROM CONNEXITE---Gilles Kahn\ldots]
Rationalising the development of software for parallel systems is
the very reason for the  existence of a company like \Connexite. The
tools that we develop must scale up to the requirements of commercial
and technical applications. The tools's users are professional and not
necessarily programming language or system architecture specialists.
The development must be guided by an intuitive interface  and alternatives 
must be presented in a simple manner.

(It also seems to meet the aims of 3.6, namely:
\begin{quote}
	Provision of distributed programming environments, O/S and
networking software, complant with emerging standards.
\end{quote}
)

[FROM CONNEXITE---Gilles Kahn\ldots]
We propose to build a state-of-the-art programming environment
that supports the dissemination of library components over a network,
client-server execution of the various tools, uniform man-machine interface
that follows standards such as OSF MOTIF and promotes a uniform presentation
of programs, interoperability of the environment's components using
emerging standards for intertool communication.


[FROM SIEMENS\ldots] 
Portable languages like HPF are best supported by portable tools for runtime
analysis. Thus architecture independent programming is supported. The
ease of program development is especially supported by visualisation tools
which are easy to learn and support the programming and analysis
process substantially.
Moreover application independent tools  provide generic, general purpose
software. Since they support a specific programming paradigm, the environment
of HPCN systems is improved.

[FROM IBM (16/4/93)\ldots]
Run-time graphics is an important tool in a large number of fields.
Graphics has been widely used in both program and algorithm debugging.
Parallel graphics will thus be an important tool which will
rationalize the development of software for parallel systems.
Due to the level structure of the graphics library, one can expect
high performance (i.e. small overhead) in calling these routines on
a number of different parallel processing systems (DM-MIMD).


\newpage


% }}}
% {{{  \section{Dependencies and Relationships} -- old stuff
\section{Dependencies and Relationships} -- old stuff

[FROM BES\ldots] 
The HPF intermediate code optimizer will be developed using as input
a programming environment that is being partially developed in an Eureka
project, which consists of an HPF to Fortran 90 $+$ MPI translator, 
a source-level debugger 
and a profiler. The debugger and profilers developed under that project 
will be enhanced and integrated into a single tool. Even though the tool 
will be targeted to that programming environment it could also be ported 
to any programming environment based on source translation.

The basic technology to develop the source-to-source transformation tools
(source code optimizer and intrinsic/library generator) will be imported 
from a technology that is being used to implement the translator for the 
programming environment mentioned earlier.

[NEW FROM BES...]
- Eureka project will provide input on software (task 3.4).
- Technology for pattern-matching is done independently of Eureka although will
  be used in Eureka too.

- It will influence the Eureka one by making what is being done there more
  complete and by perfecting some of the shared technology (pattern-matching).

- Maybe it would be good to be associated to the Eureka project, there will be
  a lot of users of HPF in that project and probably they would be a good field
  to try the tools developed in HPF-Tools. Nevertheless as I told you the
  project has been delayed for 2 months by France who is the leader. Maybe
  Connexite will have better information about what will France finally do.



[FROM SIEMENS\ldots]
As in PPPE the HPF runtime analysing tools will be portable. 
\sortout{But in contrast to
PPPE they will not be based on the European approach PARMACS, but oriented
toward the intercontinental MPI standard}, being discussed right now in
the US.  \sortout{Moreover PPPE does not develop visualisation tools.}
The observation of the HPF and the emerging MPI standards is one
objective of the Esprit proposal PROPS. In contrast to PROPS our
work will result in comfortable tools both for the system and the application
developer.


[FROM IBM (16/4/93)\ldots]
Due to the programming design used, the graphics library will be
easily portable between several different communication tools. Presently
a part of the library is running using PVM, but it has also been used
under Trollius. EUI and/or MPI could be the next target systems.

[IBM - NEW STUFF\ldots]
ParViz project at IBM Bergen Environmental Centre will provide initial
input to this project. ParViz was developed for message passing
computers and has worked with Trollius and PVM on both a Transputer
based parallel machine (IBM's Victor, experimental machine) and
networks of workstations.


[FROM TELMAT (19/4/93)\ldots]
The test and evaluation phase of the "HPF-Tools" Project will generate a 
variety of wide ranging, but influential information, concerninig the use of 
HPF. The proposed PROPS project is targetted at the expansion of the HPF 
specifications, and will benefit from the detailed information that will arise
from "HPF-Tools" eg. optimisations, programming styles, higher level tools etc.

Software arising from "HPF-Tools" will be directly useful to other projects 
eg. those related to parallel porting of software. Indeed, the possibilities 
for use as training aids in the European COMETT Training programs are numerous.

[INRIA, NEW STUFF\ldots]
The project inherits the considerable technical experience
in building programming environments of the Gipe and GipeII
Esprit projects, as well as the experience of Connexite (an
Esprit spinoff of Inria) in marketing Fortran development 
and reverse-engineering tools.

[TUM -- NEW STUFF\ldots]
input: international discussion on common trace formats (i.e.\ the
Supercomputing 90 session on standardizing parallel trace formats)

output: another proposition of common trace formats with an access function
library, which meets the HPF requirements and the requirements of existing
environments and tools also (as far as possible), which includes compressing
support, and which is freely available


\newpage

% }}}
% {{{  \section{International Standards} -- old stuff
\section{International Standards} -- old stuff

[FROM BES\ldots]
All the tools will comply with the HPF standard and its availability will
encourage the use of HPF.

[FROM SIEMENS\ldots]
The visualisation tools will be based as far as possible on MPI, the
emerging standard for message passing interfaces.

[SIEMENS -- NEW STUFF\ldots] OSF/MOTIF for visualisation

[FROM TUM\ldots]
Up to now there exist no international standards for trace formats.
\sortout{If some (special) trace formats will be standardised during the 
project run time they will be included into the developed trace format.}

[FROM IBM BERGEN\ldots]
Graphics library will be initially written with X-windows/Motif.
Future development could include Open GL and Phigs.

[FROM IBM (16/4/93)\ldots]
Graphics: X-Windows/Motif, future, if the target user group is moving
   in this direction: OpenGL and/or Phigs.
   Communication: PVM, future, the direction of the target user group: MPI, 
   EUI (?). 

[INRIA, NEW STUFF\ldots]
\bi
	\item X11
	\item OSF/Motif
	\item Z39.50-92 (incorporating SR).  This is the basis to the 
Wide Area Information Source (WAIS) system.
	\item industry client/server protocol (e.g., Tooltalk, CORBA)
\ei	

\newpage

% }}}

% {{{  \section{Baseline and Rationale of the Project}
\section{Baseline and Rationale of the Project}

% {{{  \subsection{Baseline}
\subsection{Baseline}

% {{{  background -- types of Fortran

Fortran has always held a dominant position in scientific
programming.  Relatively unambitious in scope
compared with more modern programming languages, its simplicity nevertheless
lends itself naturally to automatic optimisation.  A large
subset of typical scientific and engineering applications do not
essentially depend on features like pointers
and contemporary data encapsulation techniques.  Their absence has
facilitated extensive static analysis and consequent transformation.
This, in turn, has enabled successful automatic vectorisation of
sequential code, and more limited success with semi-automatic
parallelisation.
[REFERENCES TO VECTORIZATION TOOLS, SHARED MEMORY PARALLELIZERS]

In an independent line of development, various vendor-specific data-parallel
extensions to the Fortran have been notably successful in exploiting
SIMD architectures.  The outstanding contemporary example is
perhaps Thinking Machines' {\em Connection Machine Fortran}.

Recent years have seen a number of attempts to combine features from
these two threads (vectorization and data-parallelism).  These systems
take Fortran 77 programs extended by directives prescribing data
distribution and alignment.  Typically, they target distributed-memory
MIMD rather than SIMD hardware.  Such systems can be viewed as tools
for automating the coding of an emergent paradigm in scientific MIMD
computation---{Single Program Multiple Data} (SPMD) programming.  They
relieve the programmer of the need to explicitly insert
communication.  Archetypical examples are Rice University's {\em FORTRAN D},
and {\em Vienna Fortran}.

The focus of these efforts has shifted with the acceptance of
the Fortran 90 standard, which contains explicit syntax for expressing
data-parallel computation.  This facilitates the extraction of
parallelism---because the programmer can express parallelism explicitly,
there is a reduced requirement to depend solely on extensive static analysis
for isolating parallelism.
(Simultaneously, some of the limitations to Fortran mentioned above
have been relaxed).
However Fortran 90 does not provide any support for programmer-defined
{\em placement} of data.

% }}}
% {{{  background - HPF

In the last year the {\em High Performance Fortran Forum} (HPFF), a coalition
of many leading industrial and academic groups in the field of
parallel processing, has established an informal standard called
{\em High Performance Fortran\/} (HPF) for extensions to Fortran~90 
for data-parallel computations on multi-processor architectures.  In 
particular, HPF includes directives for specifying, at various levels
of abstraction, how program data should be distributed over virtual or
actual processor memories.  The standard is supported by a majority of 
vendors of parallel hardware, including Cray, DEC, Fujitsu, HP, IBM, 
Intel, Maspar, Meiko, nCube, Sun and Thinking Machines.
Several vendors have already announced their intention to develop
HPF implementations, including hardware vendors
DEC, Intel, Maspar, Meiko, Thinking Machines,
and compiler vendors ACE, APR, KAI, Lahey, NA Software, Portland and PSR.

An official subset of HPF (`Subset HPF') has been defined to facilitate
early implementations.  It is expected that the first true Subset
HPF implementations, implemented as translators to Fortran plus 
message-passing, will appear at the end of 1993 or start of 1994.
(At least one vendor has already announced a release of a Subset HPF
compiler, but this is misleading as it does not support the {\em full\/}
`Subset'!).
% }}}

The consortium of this project brings together an impressive
range of experience relevant to programming in HPF.

% {{{  Soton

The University of Southampton has since 1989 been involved in the research
and development of a system called `ADAPT' (`Array Distribution Automatic
Parallelisation Tool') for automatically transforming Fortran~90
supplemented by data distribution declarations for distributed memory
message-passing architectures \ref{adapt}.  This research started in the
Esprit PUMA project, and has established Southampton as one of the leading
groups in the field of HPF-like langauge research.

The input langauge for this system, called `Distributed Fortran~90',
may be considered a precursor for HPF, like Fortran~D and Vienna Fortran
(though our research actually started slightly before these).
Since `Distributed Fortran~90' comprises Fortran~90 plus data distribution
declarations, it was obviously directly relevant to the HPF design and
development, and a technical report of the ADAPT research\ref{adapt-tech} 
was one of five or six major input documents to the HPF activity.
Indeed, this was the only research to study the implications
of Fortran~90 for this field, other research (e.g. Fortran~D and Vienna
Fortran) having concentrated on Fortran 77.

Southampton has had a considerable input and influence on the development 
of HPF, both by email input and, in the latter stages, by attendance at
HPFF meetings supported by the Esprit PPPE project.  Among
Southampton's contributions to HPF are:  the \verb@PURE@ procedures;
elemental reference of pure procedures (which was dropped at the last moment 
to minimise direct extensions to Fortran~90, but which is nevertheless
likely to be included, with pure procedures, into full Fortran~90 
at the next minor revision in 1995); 
the treatment of array-valued sections and expressoins across 
procedure boundaries;  
disallowing remapping of \verb@COMMON@ block data;  
the lexical form of HPF mapping directives;
much editorial work (we are currently on the editorial committee for the
final HPF draft).



% }}}

% {{{  inria

\Connexite (together with its founding partners INRIA and SIMULOG)
boasts 120 man years of research in interactive programming
environments.  [ADD SOMETHING ABOUT FORESYS].

INRIA's expertise in programming environments began with the Mentor 
system and continued under the Esprit program with the Gipe projects, 
"Generation of Interactive Programming Environments", Gipe (1984--1989) and 
Gipe II (1989-1993).  
In the area of Software Development Environments, the major international
conference is that of the ACM SIGSOFT SDE conference, which is held every 
two years.  Gipe II results, including system architecture, programming
environment techniques, and intertool protocol, have been presented at
the last three SDE conferences, thus confirming the techniques and tools 
developed within Gipe are of a high standard.

% }}}
% {{{  bes

While working for an American company, leading staff at BES designed
and implemented a complete Fortran 90 to FORTRAN 77 translator.  In
conjunction with native FORTRAN 77 compilers, the translator provides a
Fortran 90 programming environment portable across a wide range of
computers.  Currently BES is participating in a Eureka project.  There it
is responsible for producing an HPF programming environment based on
a translator. The programming environment will be complemented with a
source-level debugger and a profiler.

% }}}

% {{{  siemens

Siemens, who will take a leading role in the HPF ``performance
visualisation'' tasks of the project, have previously implemented a
visualisation and control environment called VISIT \cite{IlmWie93} for
DM-MIMD programming.  This provides a sound platform for visualising
parallel programs, as an adjunct to optimisation.  Extensive use of
VISIT during the Esprit II project EDS demonstrated how software
development may be rationalised by the use of adequate tools. Their
close collaboration with Ken Kennedy and his group (a driving force
behind HPF and state of the art parallel Fortran environments) will be
of considerable benefit in their role of developing an integrated
visualisation environment for the HPF community.
Their associated partner TUM brings to the project long term experience in trace
based monitoring \cite{Eichholz88} and trace compression.

% }}}

% {{{  ibm
IBM BSC have been involved in parallel computing, graphics and
large scale scientific computing since their foundation in 1986.
Their graphics research, which forms the baseline of their
contribution to this project, was driven by
the need to visualize the variables of models used in Environmenal Sciences.
A post-processor
graphics environment, ADVIZE (ADvanced VIsualiZation Environment),
came out of this work. ADVIZE is an interactive 3-d visualization
environment for analyzing and presenting scalar and vector data.
It has been used by a number of international labs.
They have parallel computing experience with both Shared Memory
and Distributed Memory computers.

% }}}
% {{{  telmat

Finally, Telmat Informatique have been involved in the design and
commercialisation 
of parallel systems since 1985.
Those years of designing and
constant refinement have provided them with a strong appreciation
of the needs of their end-users in terms of programming tools.
This puts them in a strong position to effectively evaluate
and provide user-oriented feedback concerning the tools
produced in the rest of the project.

% }}}

% }}}
% {{{  \subsection{Rationale}
\subsection{Rationale}

% {{{  bryan's initial bit
    HPF is a significant step forward from explicit SPMD programming
with message-passing, towards a style of programming familiar to the
ordinary Fortran programmer.  On the one hand quite general parallel
algorithms can be encoded, but communication is managed entirely
transparently by the compilation system.  On the other hand, the
language has been designed with a view to permitting direct
message-passing {\em implementation} on distributed-memory systems,
generally avoiding the overheads of simulated shared memory.

     However, writing efficient HPF code is by no means a trivial
task.  The programmer will need a good a understanding of what the HPF
mapping directives mean, in order to use them effectively.  Indeed, the
high-level nature of the language means that it will be very easy to
write hugely inefficient code.  Deceptively simple programs can
translate to code involving enormous amounts of communication.
The situation is aggravated by the fact that early implementations
are unlikely to be highly optimising---implementors are bound
to concentrate on providing the prescribed parallel semantics, before
they turn to optimisation.

     The project proposes to provide a set of tools for easing the
transition to HPF, and tuning and debugging HPF codes.

% }}}

     [RATIONALE OF OUR WP1 TOOLS]
% {{{  inria

%[INRIA, NEW STUFF\ldots]
%The task of programming in HPF is difficult.  The end user needs help from the 
%computer to make his code the most efficient.

     A well designed environment with an intuitive user interface will
greatly increase the programmers productivity.
[NEED MUCH MORE ON CONNEXITE/INRIA WORK]

% }}}
% {{{  bes

%[FROM BES\ldots]
% Vaguely relevant, but too long, given what everyone else hasn't said.

   The work proposed by BES in this project is a natural extension of their 
current work.

The source-to-source transformation tools (intrinsic/library generator and
source-to-source optimizer) were planned spin-offs of the technology currently
being developed in BES and will be necessary complements to any
programming environment for HPF.

The HPF intermediate code optimizer will complement the programming
environment for HPF that is currently being developed by the company,
providing a specific solution for HPF programming in environments
supported by a translator.
% That's rather unconvincing

%The necessity of such tools comes both from their actual existence in
%programming environments for more established languages (i.e. the existence of
%source-to-source optimizers for C or FORTRAN 77) and from the specific needs
%in optimization that will be found when programming in HPF. Specifically, in a
%parallel computer the optimization issues will be more important that in a
%sequential or vector one.

% }}}
% {{{  siemens

%[FROM SIEMENS\ldots]
Visualisation of program execution on HPF and intermediate language level
reduces the turn around time for the development of satisfactory
HPF compilers and efficient HPF programs.
% Brilliant

% }}}
% {{{  tum

%[TUM -- NEW STUFF\ldots]
without common trace formats HPF visualisation is a stand-alone solution,
which cannot reuse other visualisation tools, and whereby the possibility
of comparing results with other environments on visualisation level is not
given
% Boring, or what.

% }}}
% {{{  ibm

%[IBM - NEW STUFF\ldots]
% about right

There is a great need to visualize the progress of todays large scientific
codes. The amount of data is often so vast that computer graphics is needed
to grasp this amount within a short time. The HPF Graphics tool will meet
this need and supply the Fortran programmer with a set of simple callable
routines that will help in grasping the needed information.

% }}}


%[ROMAN POINTS OUT: I think it would be good to put here or somewhere else a 
%classification of the tools based on which ones are tied to particular 
%programming environment and which ones can be used on any HPF programming 
%environment.
%
%In our case the integrated debugger and profiler is tied to the programming
%environment we are developing in Eureka (althouth it could be ported to
%any other programming environment based on a translator. The other two tools
%are not tied to a particular programming environment and could be used by
%anyone programming in HPF.]

% Roman's probably right, but there isn't time to sort this out.


% }}}

% }}}









% }}}

% {{{  Telmat crap -- what do I do with this??
From ddu@TI-1 Sat Apr 17 20:49:21 1993
Received: from [080039002d26/DCC.38826110000503030002020103] by bright.ecs.soton.ac.uk; Sat, 17 Apr 93 20:40:39 BST
Received: from corton.inria.fr by sun3.nsfnet-relay.ac.uk with Internet SMTP 
          id <sg.10825-0@sun3.nsfnet-relay.ac.uk>;
          Sat, 17 Apr 1993 10:05:59 +0100
Received: from telmat.UUCP by corton.inria.fr (5.65c8d/92.02.29) via Fnet-EUnet 
          id AA21665; Sat, 17 Apr 1993 10:19:04 +0200 (MET)
Message-Id: <199304170819.AA21665@corton.inria.fr>
Subject: More stuff for you
To: jhm (John Merlin Univ Southampton)
Date: Sat, 17 Apr 93 8:57:02 ETE
From: Dominique Duval <ddu@TI-1>
Organization: Telmat Informatique - FRANCE
Reply-To: duval <duval@fr.telmat>
Return-Path: <duval@telmat.fr>
X-Mailer: ELM [version 2.3 PL11]
Content-Type: text
Content-Length: 8999
Status: OR

Please find hereafter a new version of Telmat things for the new Esprit call.
It is clearly coming  bit late but you may find it better written than the old 
one and maybe would like to swap them.

Cheers,
Dominique


                    The evolution of Massively Parallel Processing


        Through the Esprit programmes, the CEC has supported several important
        research  and development activities which have built some of the  key
        technologies  required  for  the next generation of  high  performance
        computing  and  networking (HPCN) systems.  These two areas will  show
        dramatic  growth in the latter half of the decade and into the  twenty
        first  century.  High performance computing will migrate more and more
        from  national  research and defence laboratories into the  industrial
        mainstream   in  such  diverse  areas   as  CAD/CAM  and   engineering
        simulation,  realistic animation for market research and  advertising,
        large interactive databases and robotics vision.


        The years 1985-1990 can be regarded as the research phase of Massively
        Parallel   Processing  (MPP).   During   this  period  the  pioneering
        companies,  which  were nearly all small startups, developped  systems
        based  on a wide variety of architectures and programming models.  The
        research  phase was funded primarily by government grants and sales of
        prototype  systems  to  universities and research  centers,  and  more
        recently  venture  capital.  Early customers were computer  scientists
        and  scientific  computing specialists.  Once familiar with  this  new
        programming paradigm in computing, users ported the naturally parallel
        and  power hungry applications to demonstrate the promise of MPP.   In
        this  early  phase,  the  technology  has  made  few  inroads  in  the
        industrial  mainstream,  due to the lack of parallel versions  of  the
        third party application software packages.


        Although Europe is lagging behind the accelerating international
        usage  of High Performance Computing, MPP is a new area where european
        products and technology are competitive, backed by considerable
        expertise in European industrial and academic research.

        The world wide market for High Performance Computers is estimated as
        $5.7 billion in 1991. Supercomputers, Mini-supercomputers and MPPs
        account for nearly 30% of the total market value. The MPP sector is
        reported by IDC to show the highest growth rate overall, and is
        forecast to stay the fastest growing, as MPP becomes a dominant
        sector in the market.

        The report produced by the european working group chaired by
        Professor Carlo Rubbia, Director General of CERN and Nobel prize
        winner, advocates a european plan for high performance computing,
        which will close the gap with the US and Japan.


        Performance Computing Industries

        Performance Computing Industries (PCI) is a consortium consisting of
        three major european parallel computer specialists : Meiko Limited,
        Telmat Multinode, and Parsys Ltd. PCI will operate as a European
        Economic Interest Group (EEIG) in the markets for high performance
        computing. PCI's strategy is to develop and market MPP systems based
        on commodity microprocessors, I/O subsystems, operating systems,
        compilers and libraries. Currently, PCI installations are estimated
        to account for 29% of the total world wide installed MPP base, and
        over  60% of the installed MPP base in Europe and countries other than
        the USA.

        The Con,certo system, ofgficiaally introduced by PCI in early 1992,
        is based on SPARC and INTEL i860 processors. A total of over 50
        systems have been installed to date in over a dozen countries
        worldwide.

        The new CS-2 High performance computer was initially released early
        93. Prototype systems based around new processing nodes and
        integrated  with Elan/Elite communications networks are already in use
        at a few selected sites.


        The CS-2 machine

        The CS-2 is an evolving massively parallel supercomputer capable of
        the intensive computation required by users in science and commerce.
        It is a distributed memory MIMD machine made up of from 4 to 1024
        processor nodes. The nodes contain commodity high performance RISC
        processor and memory chips (from 16 to 128 Mbytes with 4 Mbits
        technology).

        The node perfiormance is 55 SPECMARKS with a peak floating point
        performance of 50 MFLOPS.  Optional high performance vector processing
        units can be used to further boost a node's computational power to
        200 MFLOPS (64 bits arithmetic).

        Nodes  are connected by a very high performance interconnection scheme
        using  specialised communications processors at every node and a multi
        stage crossbar switch.  Each of these processors supports 100 Mbytes/s
        of bi-directional bandwidth and the CS_2 architecture allows up to
        four such processors to be connected to a node. I/O sub-systems can
        be connected to every node allowing input-output capability to be
        scaled and tailored to meet the specific requirements of an
        installation. The Ethernet, FDDI, SCSI-2 and HiPPI standards are all
        supported. Up to 4 Tbytes of commodity disks can be connected to a
        CS-2.

        A SVR4 conformant UNIX operating system is provided on each node and
        used to support both interactive and production environments.  A range
        of parallel programming techniques are supported including data
        parallelism and message passing.


        Key Personnel Curricula Vitae

        Dominique Duval

        Dominique Duval graduated in Mathematics and Physics, and then in
        computer  science allied to business at the Universite de Haute Alsace
        in Mulhouse.

        Then he joined the Institut de Recherches Polytechniques to obtain a
        DESS in industrial system software. At Telmat, he was first a
        software developper working on UNIX systems. His first job consisted
        in developing a multi-processor version of UNIX system V for the
        Telmat range of servers.

        At the end of the Supernode project Esprit project, he joined the
        Parallel Division where he was part of the Supernode II definition
        phase, while working on the integration of third party compilers and
        the development of system software for the T.Node parallel computer.

        Dominique  was the manager of the system software team for a period of
        two years. He currently is in charge of technical product marketing
        and  support for the CS-2, and is also heavily involved in cooperative
        programs, including programs for code migration.



        TELMAT Multinode


        TELMAT  Multinode  is  one  of  the companies  of  the  TELMAT  Group,
        officialy  created  in  early  1993  to   regroup  its  team  of   MPP
        specialists.   This  activity was started in 1985 through one  of  the
        first ESPRIT project, SUPERNODE, whose purpose was to design and build
        a  transputer  based MPP system.  TELMAT started shipping products  in
        1989 and since then has installed about 70 in 9 european countries.

        TELMAT Multinode markets two lines of products :

        -  transputer based systems with the T.Node / Meganode range and a new
        line of systems based on the T9000 latest transputer version.

        -  Heterogeneous systems for scientific computing such as the Concerto
        and CS2 systems, developped by PCI, a consortium of european companies
        specializing in MPP technology in which TELMAT is a member.

        TELMAT  Multinode is basically an expert in parallel processing :   in
        addition,  its applications department embodies a strong experience in
        scientific  computing  and parallel algorithms and its  engineers  are
        experts  at  running,  porting, parallelizing and  optimizing  Fortran
        programs on Telmat's machines.

        The  TELMAT  group  has  been involved in a  number  of  international
        cooperative  programs,  such  as  ESPRIT and AIM.   Under  the  ESPRIT
        program,  the  TELMAT  Group has been or is working in  the  following
        projects  :   Supernode,  Supernode 2, GP MIMD, GP MIMD  2,  Papagena,
        Humanoid, Spirit, Spectre, VIMP, Fodatec.

-- 
--------------------------------------------------
Dominique Duval
Telmat Informatique
BP 12
Rue de l'Industrie
68360 SOULTZ
FRANCE

Tel : +33 89 76 51 10
Fax : +33 89 74 27 34
email : duval@telmat.fr
--------------------------------------------------



% }}}
% }}}
