(j3.2006) Paper submission

Mon Jun 13 12:42:54 EDT 2011

Van points out that he has submitted a paper suggesting similar
changes in 11-172.txt.

-craig

On Mon, Jun 13, 2011 at 10:22 AM, Micki St. James
<mickistjames at gmail.com> wrote:
> 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
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>