Subject: Survey results concerning some F90 issues.

From: Richard Shapiro <[email-masked]>
Date: Tue, 2 Jun 92 13:53:54 EDT

I sent out a brief survey to Fortran users at both United Technologies Research
Center and Thinking Machines. The survey is below:

-----------------------------------------------------------------------
As part of the High Performance Fortran Forum, I've been asked to survey
users as to how they feel about certain aspects of the language.  Please
give me feedback. 

Issue #1: Character data.

How important is it to you for HPF to support parallel operations on
character data?  CM Fortran, for example, does not support parallel
operations on character data. 

Issue #2: Sequence association

How important is it to you for HPF to support sequence association on
distributed data (sequence association is that property of an array which
specifies the order in which array elements are stored in memory, and
allows one to reshape arrays through subroutine calls, for example)?
CM Fortran does not support sequence association on distributed arrays.

If sequence association should be supported, what should the default for a
distributed array be? In otherwords, if unspecified, should the compiler
assume that an array is sequence associated or not sequence associated.

Issue #3: Storage association

How important is it to you for HPF to support storage association on
distributed COMMON blocks?  

If storage association should be supported, what should the default for a
COMMON block be? 

An example of storage association:

In subroutine1:

	COMMON /FOO/ A(100),B(100)

In subroutine2:

	COMMON /FOO/ C(200)

C(101) refers to the same memory as B(1).

Thank you in advance for taking the time to respond.

		Richard Shapiro,
		United Technologies Corporation
		([email-masked])

----------------------------------------------------------------------

Here is a summary of the responses:

I got responses from 4 people at UTRC (all users, counting myself), and 7
people at Thinking Machines (2 compiler developers, 5 users). 

Issue #1: CHARACTER data

	2 would like it, 6 don't care.

Issue #2: Sequence association

	5 would like it, 2 don't care.
	Of the responders, 3 think the default should be no sequence
	associated, 1 thinks the default should be sequence associated.

Issue #3: Storage association

	6 would like it, 3 don't care.
	Of the responders, 3 thinks the default should be not storage
	associated, 2 think the default should be storage associated.

---------------------------------------------------------------------

The actual responses follow:

Date: Mon, 11 May 92 11:58:09 -0400
From: [email-masked] (Brice Cassenti)

Rich, below are my thoughts on your little survey.  Brice

Issue #1: Character data : Not important

Issue #2: Sequence association : Improtant. The default should be no
sequence associated

Issue #3: Storage association : Not important

-----------------------------------------------------------------------------
Date: Wed, 6 May 92 16:29:17 EDT
From: Doug MacDonald <[email-masked]>
Sender: [email-masked]
To: [email-masked]
In-Reply-To: Richard Shapiro's message of Wed, 6 May 92 15:48:07 EDT <[email-masked]>
Subject: A little opinion survey

   Issue #1: Character data.

   How important is it to you for HPF to support parallel operations on
   character data?  CM Fortran, for example, does not support parallel
   operations on parallel data. 

Not.  I can't see HPF being used as an implementation language for database
projects, can you?

   Issue #2: Sequence association

I don't understand what this means.  If CM Fortran doesn't support it, it's
obviously not array layout.  Is there anything on line that I can read to
get the definition?

   Issue #3: Storage association

   How important is it to you for HPF to support storage association on
   distributed COMMON blocks?  

This seems like a very good idea.

   If storage association should be supported, what should the default for a
   COMMON block be? 

Do you mean, should the COMMON blocks below, if in different procedures or
block data programs, refer to the same memory by default?  Yes.

-----------------------------------------------------------------------------
Date: Wed, 6 May 92 15:30:16 CDT
From: [email-masked] (Anthony L. Kimball)

   Issue #1: Character data.

Not.  Give me structures first.

   Issue #2: Sequence association

This explanation of sequence association is completely opaque to me.

   Issue #3: Storage association

It is evil.  I can't tell you how many wasted hours I've spent on
such code (written by maniacs).

-----------------------------------------------------------------------------
From: Woody Lichtenstein <[email-masked]>
Date: Wed, 6 May 92 16:35:46 EDT
Subject: A little opinion survey

It is possible to support a notion of sequence association
within local memory without full global sequence association.
Local sequence association is useful for programming and need not
have any performance impact.

-----------------------------------------------------------------------------
From: Alex Vasilevsky <[email-masked]>

   Issue #1: Character data.

What do you mean by parallel operations on characters?  Do you mean that
array operations on characters should be parallelized by the compiler?  If
so, what does that have to do with language defining something to be
parallel?  The semantics of the language that will run on workstations
should not define anything to be explicitly parallel.

   Issue #2: Sequence association

Yes, it should be supported for distributed arrays completly across the
machine, and not partially.  The compiler can linearize the array and make
it all work, albeit slow on some computers.

It should only be supported as compatibility with full F90 or scalar codes.
The switch that specifies the sequence association should be on by default.
The user should have the ability to turn this off.

   Issue #3: Storage association

Important.

   If storage association should be supported, what should the default for a
   COMMON block be? 
Yes.  Default same as sequence associtaion.

All codes written in F77 must work in this language, and since all of F77
is in HPF then it *must* support standard F77 semantics on memory.

There should be a capability build into the language through directes or
whatever elese, that allow one to go away from Fortran 77 memory model.

	-Alex V.

-----------------------------------------------------------------------------
From: Robert Ferrell <[email-masked]>

   Issue #1: Character data.

Not important.

   Issue #2: Sequence association

This would be nice mostly for existing codes.  I do not think I would use
this feature in new codes, since sequence association is often used for
memory management, and there are much better memory management techniques
available.

   If sequence association should be supported, what should the default for a
   distributed array be? In otherwords, if unspecified, should the compiler
   assume that an array is sequence associated or not sequence associated.

Not sequence associated.

   Issue #3: Storage association

Same as above- important only for old codes.  

   If storage association should be supported, what should the default for a
   COMMON block be? 
Not storage associated.

-----------------------------------------------------------------------------
From: Bernie Murray <[email-masked]>

Issue #1: Character data.

I wish I had this before, I'm sure I'll want to use it in the future.
Is there some big problem implementing this on the cm5 ?

Issue #2: Sequence association

This sounds handy.  I like optional user control.
Your fault, my fault, default, doesn't matter to me.

Issue #3: Storage association

I've gone thru a lot of hassles to get storage association tricks 
to work in other languages.  Why not make it easy on me.

It's always easy to ask for further fugacious future features.
Bernie

-----------------------------------------------------------------------------
Date: Thu, 7 May 92 08:48:55 -0600
From: [email-masked] (Steve Goldhaber)

All three of the proposed features would make life easier for
porting codes to parallel machines. In addition, the sequence
association feature would make some optimizations more clear. I
would vote fairly strongly for all three although their absence
hasn't been as bad as things like nested where statements and lack
of I/O support.

-----------------------------------------------------------------------------
Date: Thu, 7 May 92 16:28:43 -0400
From: [email-masked] (Brian Wake)
Subject: survey
To: [email-masked]
X-Envelope-To: [email-masked]

 None of the items are important to me at this time.
brian wake

-----------------------------------------------------------------------------
Date: Thu, 7 May 92 16:47:56 -0400
From: [email-masked] (Alan Egolf)

#1  Very limited value, almost nil.

#2  I don't personally do this, and I don't like code which is written this
way.  I believe it is a drawback to days when memory was very limited. 
However, I can see some benefits for some problems.  As such, I see low need
for this feature.  I have no current opinion on the second part of this
question.

#3  I have found this benefical in some cases.  For instance

common/data/ xyz(100,3)

in subroutine a

and 

common/data/ x(100),y(100),z(100)

in subroutine b

for programing convenience

I would rate this as useful, with moderate to low need.

Alan

------------------------------------------------------------------
From: Richard Shapiro <[email-masked]>

   Issue #1: Character data.

Not important

   Issue #2: Sequence association

Important, but not the default

   Issue #3: Storage association

Not important, and not the default

---

From: John Merlin <[email-masked]>
Date: Thu, 4 Jun 92 18:48:16 BST

>	...stuff omitted...
 
> 	associated, 1 thinks the default should be sequence associated.

I'd like to take issue with "Issue #2: Sequence association".

In F77 one often *had* to resort to this (e.g. passing an
array element as the actual argument corresponding to a dummy 
array, or reshaping an array parameter across a procedure
boundary, or using assumed size arrays) -- there was no other 
(simple) way of achieving the desired effect.  Better and more 
general ways of achieving these effects are made available by 
the array syntax of F90, viz. by using array sections as actual 
arguments, and using the RESHAPE intrinsic and assumed shape dummy 
arrays.  Since it's proposed to include these features in 
Subset HPF, users can readily modify their codes to avoid 
these undesirable (and deprecated) aspects of sequence association.

There's another important point -- F90 actually *forbids*
shape disagreement between actual and dummy arguments if the
procedure interface is specified in an INTERFACE block.
I believe (and hope) that HPF may require the use of interface 
blocks in at least some circumstances when actual and or dummy 
arguments are distributed, so one won't be allowed to use these
sequence association features according to F90.  I wonder
how many of your respondants who said 'yes' were fully aware 
of these issues?

Therefore, I don't think one should beat one's head trying to
support sequence association in a model where its basic 
assumptions clearly don't apply, namely for distributed data
in HP Fortran -- particularly as simple and recommeded alternatives
exist.  As you mention, CM Fortran users live without it, presumably
withuout too much pain.  (Of course, there's no reason to disallow 
sequence association for non-distributed data.)

                       Best regards,
                          John Merlin

-----------------------------------------------------------------------
John H. Merlin                               email: [email-masked]
Dept. of Electronics and Computer Science,   tel:   +44 703 593368
University of Southampton,                   fax:   +44 703 593045
Southampton S09 5NH,  U.K.