Subject: Re: hpff: July HPFF Meeting Minutes

From: [email-masked] (Rob Schreiber)
Date: Tue, 12 Sep 1995 14:17:49 -0700

---------------------------------------------------------------------------
[email-masked] is a mailing list for announcements related to High
Performance Fortran.  Instructions for adding or deleting yourself
from this list appear at the bottom of this message.
---------------------------------------------------------------------------

I think that a standard descriptor format would be
a good idea, but it should be in the form of a fortran 90
derived type, that can be replicated, for example, and passed as
an ordinary parameter to an extrinsic routine; then a library
routine would be used to set it up:

	interface
	   extrinsic (c_local) function c_local_fn(desc)
           integer c_local_fn
           type (mapped_array_descriptor) desc
        end interface

	type (mapped_array_descriptor) x_desc
	real, x(100,200)
!hpf$ distribute x(block, *)

!
!   call an hpf library routne to create the exportable 
!   array descriptor for x
!
	x_desc = create_mapped_array_descriptor(x)
	call c_local_fn(x_desc)

---------------------------------------------------------------------------
To (un)subscribe to this list, send mail to [email-masked].  Leave
the subject line blank, and in the body put the line
(un)subscribe <email-address>
---------------------------------------------------------------------------

---

From: [email-masked] (Scott B. Baden)
Date: Tue, 12 Sep 1995 17:06:51 -0700 (PDT)

Rob,

As a follow on to this: what about the converse, that is
calling HPF from another languge (e.g. C++)? In this case
HPF is viewed as the extrinsic language.

This has gotten somewhat bogged down (apparently in part
due to leadership changes in the C++ committee),
but it would be nice to discuss this next week.

I've had some prelimenary discussions with Chuck.
It appears that Annex A is a good source of ideas for
deriving  the facilities that would be needed on the C++ end.
(This isn't surprising since we are in effect providing
facilities that mirror the HPF-to-external interface)

To get the ball rolling.  Let's say we have an SPMD program,
that is a group of processors (e.g. an MPI communicator)
all executing the same program in loosely synchronous fashion.

What we need need an etry to initialize the HPF run time system
i.e. to identify global processor arrangments.  We also need
a routine much like your create_mapped_array_descriptor(), with arguments
that specify the global shape, the processor array, distribution
and alignment and so on.

Our SPMD program collectively allocates mapped arrays,
collectively calls HPF routines.  There would have to be
some agreements worked out,  i.e. that on entry to an HPF routine
from C++ a scalar must have the same value on all processors,
(this mirrors the languge in Annex A for calling C from HPF)
and that mapped arrays called from C++ would
have to promise to match the declarations on the HPF end and so on.

We can also support task parallelism, through the use of
multiple MPI communicators.  Then we could think of multiple
SPMD programs calling different HPF routines.  

Though the facility should work in principle with any language,
at this point I would tend to be biased to C++.

Comments?

Scott

---

From: Doug MacDonald <[email-masked]>
Date: Wed, 13 Sep 95 11:24:02 EDT

Date: Tue, 12 Sep 1995 14:17:49 -0700
   From: [email-masked] (Rob Schreiber)

	   interface

   !

H'mmm... I had assumed that HPF implementations generally passed data
mapped array arguments as the address of a descriptor object.  The code
fragment above seems to assume that the mapped_array_descriptor object
doesn't already exist and needs to be created as a preamble to the call to
c_local_fn.  Why wouldn't HPF simply pass the descriptor address and count
on the called routine to examine the descriptor and do what was necessary?
This might make sense in the absence of an interface block, or in an
interface block containing transcriptive data mappings for x, or in an
interface block for certain types of extrinsic function.

Doug

---

From: "David B. Serafini" <[email-masked]>
Date: Wed, 13 Sep 1995 11:22:43 -0500

> Cc: [email-masked]

> routine would be used to set it up:

This issue was dealt with at Thinking Machines when the CM Scientific Software
Library project got started.  In order to make the SSL routines callable from
all the CM languages, an internal representation of a distributed array was
needed.  A structure was developed that contained the necessary info: (rank,
bounds, datatype, memory-location, CM-geometry (equivalent to HPF
distribution)).  It was a hard battle getting all the compiler writers to agree
to this, and compromises were made.  Maybe somebody involved with the internals
of the CMSSL could comment.  (Doug? (you brought this up).  Is rlk or cal out
there?)

-David (ex-TMCer)

---

From: Doug MacDonald <[email-masked]>
Date: Wed, 13 Sep 95 16:59:02 EDT

Date: Wed, 13 Sep 1995 11:22:43 -0500
   From: "David B. Serafini" <[email-masked]>

   -David (ex-TMCer)

Hi David!  Hope things are going well there.  When did you move from NASA
Ames to Rice?

But I'm not sure what kind of comment you're looking for... yes, we have
CMF array descriptors, array geometries, and machine geometries, but their
design is nonstandard, somewhat dated, and linked to a number of
assumptions CMF makes that don't correspond to HPF.  So sharing the details
of those could be confusing.  Anyhow, I _think_ people know in general what
kind of information is included in a mapped array descriptor (tell me if
I'm wrong or if you disagree).

I got started on this question because I'm working on ways to simulate some
aspects of HPF behavior on message-passing platforms.  To do this, it helps
to have information about an array's location, type, data mapping, etc., in
a compact form so they can be referenced as a unit, e.g., in subroutine
interfaces.  

The above will sound very familiar to you, but note that so far I haven't
mentioned a global language such as HPF.  That's because I want the scheme
to work when no global language is present.  If one _is_ there, however, I
want to be able to call a subroutine written in the global language without
a lot of overhead.

Of course, the HPFF folks usually think about it the other way around, but
a standard extrinsic descriptor (or one per extrinsic language) might be a
useful idea going in that direction as well.

Doug