(j3.2006) Paper submission

[Micki St. James]

FWIW I attended part of the HPDC
program at FCRC2011 and all of the
plenary addresses.  The current state
of academic awareness of the
role Fortran has to play in future
directions in concurrency is probably
summarized by one questioner's
comment that Fortran is the one
language that can be implemented
without a stack.  Yes, I confirmed
that the version of Fortran he is familiar with is Fortran 77.  Heads nodded in
agreement.

So I would judge that Fortran is about as separated from the other communities involved in concurrency as you could get.  We're talking cosmic space-time separation here.  
It might as well continue on its own
idiosyncratic course.

Micki 

Sent from my iPhone

On Jun 13, 2011, at 9:04 AM, "Rasmussen, Craig" <crasmussen at newmexicoconsortium.org> wrote:

> I have several comments:
> 
> 1. We had already agreed to work on this in an earlier J3 meeting.
> 
> 2. It clearly is related to interoperability with any language that
> has a thread library, like C.
> 
> 3. It is timely, concurrency is only going to increase, not decrease.
> 
> 4. The editor of MPI essentially gave up in disgust because J3 wasn't
> making progress on ASYNCHRONOUS and pulled it from the MPI-3 changes
> for Fortran.  This is why I had written an earlier email saying MPI-3
> no longer required it for MPI-3.  Subsequently, several influential
> members of the MPI Forum have said we should just pull the MPI-3
> Fortran changes altogether if we can't get the code motion problem
> fixed.  For some reason, MPI members think that being able to write a
> correctly running MPI program is more important that the syntactic
> sugar that makes up the rest of the MPI-3 Fortran changes, including
> the use of TYPE(*), DIMENSION(..).
> 
> 5. If we wait until the next standard, 5 years hence, a lot of water
> will have gone under the bridge regarding many-core processor
> advances.
> 
> -craig
> 
> On Mon, Jun 13, 2011 at 5:50 AM, Bill Long <longb at cray.com> wrote:
>> 
>> On 6/12/11 11:16 PM, Malcolm Cohen wrote:
>>> 
>>> Bill Long wrote:
>>>> 
>>>> Just as a general policy, it is not acceptable to try to edit 10-007r1 by
>>>> slipping edits into Clause 6 of the N1854 that are not related to the TR.
>> 
>> I stand by my  objection.  There is nothing in the TR text (Clauses 1-5)
>> related to this, and Craig's paper did not include edits to insert anything
>> there.   The point of Clause 6 is to provide the edits that incorporate the
>> rest of the TR into 10-007r1.  Edits that have no reference to anything in
>> the TR are not acceptable.
>> 
>>>> This should be modified to be a paper with edits to 10-007r1 and go into
>>>> the
>>>> pool of proposals for the next revision.
>>> 
>>> I think this is a spectacularly unhelpful response to a proposal to handle
>>> a
>>> real problem with interoperating with companion processors, viz the
>>> asynchronous
>>> updating of Fortran entities caused by the companion processor.
>>> 
>>> This possibility is not limited to MPI or new things like OpenCL but
>>> includes
>>> the asynchronous i/o primitives found in most operating systems and
>>> available
>>> through most C compilers.  Such primitives have even been available in
>>> ordinary
>>> retail operating systems like *BSD, Linux and Windows for well over a
>>> decade.
>>> 
>>> In fact IIRC we already debated this in the context of how can we support
>>> MPI,
>>> and decided at that to handle this in the TR.
>>> 
>> 
>> My recollection is that the MPI group specifically withdrew this request,
>> and decided to not use ASYNCHRONOUS in the new MPI interface. So, the
>> urgency is no longer there.
>> 
>>> So I strongly disagree that this is a priori off the table.  On the
>>> contrary, we
>>> have already been dinged on our apparent lack of action to support our
>>> earlier
>>> decision and communication with the MPI community!  We would do ourselves
>>> no
>>> favour by continuing to take no action on this issue.
>>> 
>> 
>> I am not a priori opposed to considering this.  However, it is a new feature
>> that is not related to the purpose of the TR (interoperability of interfaces
>> with assumed-shape. allocatable, pointer, and optional arguments).  At some
>> point we have to stop adding new features and finish the TR. I think this
>> should be considered as part of the next standard - it even fits well into
>> the idea of a "corrections" proposal.
>> 
>> This topic is squarely in the /Data bin.  If the /Data subgroup can come up
>> with an acceptable rewrite of the paper within the first couple of days of
>> the meeting, I may soften my procedural objection.
>> 
>> Cheers,
>> Bill
>> 
>> 
>>> Cheers,
>> 
>> --
>> Bill Long                                           longb at cray.com
>> Fortran Technical Support    &                 voice: 651-605-9024
>> Bioinformatics Software Development            fax:   651-605-9142
>> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
>> 
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at j3-fortran.org
>> http://j3-fortran.org/mailman/listinfo/j3
>> 
> 
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3