(j3.2006) Paper submission

Bill Long longb
Mon Jun 13 13:37:25 EDT 2011



On 6/13/11 11:22 AM, Micki St. James 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.

And yet, in HPC, where parallelism is essentially universal, Fortran 
(the current version) is very widely used.  Parallelism between nodes 
uses MPI, and more recently, coarrays.  On node, OpenMP is widely used, 
and Fortran has first-class support in the OpenMP standard.  If you look 
at GPU's (parallel in the extreme), the special PGI compiler for cuda 
came out for Fortran first, C followed much later. And the new OpenMP 
directives for GPU's are squarely aimed at Fortran users.  The guys at 
this conference might be borderline clueless, but that does not change 
reality on the street.

Cheers,
Bill

>
> 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

-- 
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





More information about the J3 mailing list