(j3.2006) Paper submission
Mon Jun 13 12:04:33 EDT 2011
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
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
>>> pool of proposals for the next revision.
>> I think this is a spectacularly unhelpful response to a proposal to handle
>> real problem with interoperating with companion processors, viz the
>> updating of Fortran entities caused by the companion processor.
>> This possibility is not limited to MPI or new things like OpenCL but
>> the asynchronous i/o primitives found in most operating systems and
>> through most C compilers. ?Such primitives have even been available in
>> retail operating systems like *BSD, Linux and Windows for well over a
>> In fact IIRC we already debated this in the context of how can we support
>> 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
>> decision and communication with the MPI community! ?We would do ourselves
>> 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.
> 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
More information about the J3