From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Sat Jun 23 05:12:48 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id B45643568DD; Sat, 23 Jun 2012 05:12:48 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail.jpl.nasa.gov (smtp.jpl.nasa.gov [128.149.139.106]) by www.open-std.org (Postfix) with ESMTP id 872C835681E for ; Sat, 23 Jun 2012 05:12:46 +0200 (CEST) Received: from [137.79.7.57] (math.jpl.nasa.gov [137.79.7.57]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q5N3ChIY000787 (using TLSv1/SSLv3 with cipher DHE-RSA-AES256-SHA (256 bits) verified NO) for ; Fri, 22 Jun 2012 20:12:44 -0700 Subject: Comment on 12-162 From: Van Snyder Reply-To: Van.Snyder@jpl.nasa.gov To: sc22wg5 Content-Type: text/plain; charset="ISO-8859-1" Organization: Yes Date: Fri, 22 Jun 2012 20:12:43 -0700 Message-ID: <1340421163.9358.273.camel@math.jpl.nasa.gov> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 (2.28.3-24.el6) Content-Transfer-Encoding: 7bit X-Source-Sender: Van.Snyder@jpl.nasa.gov X-AUTH: Authorized Sender: owner-sc22wg5@open-std.org Precedence: bulk In 12-162, Reinhold suggests that the syntax of put-with-notify ought to look as much like ordinary coarray assignment as possible. I would find a distant specification of this behavior, such as an attribute that specifies an event variable and implies asynchronous transfer in all coindexed references to the specified coarray, or cryptic syntax in an assignment statement, or a conspiracy of both that nobody could understand, to be undesirable. This is one of the reasons that I suggested unformatted internal asynchronous data transfer statements as an alternative that we nearly already have, that most would instantly understand, and which would have additional uses. We would need to do only two things. First, we would need to define (independently from asynchronicity and coarray internal files) what unformatted internal data transfer does, which is trivial -- even easier than formatted internal data transfer. A competent processor ought to provide performance equivalent to a sequence of assignment statements. Second, we would need to allow an asynchronous data transfer statement to specify either an event variable or an integer in the ID= specifier. This is desirable in any case. Fine-grain parallelism is discussed in 97-114r2 (section 18), 00-317, 03-258r1 (section 1.5), 06-187, and 08-202. Processors already have the technology at hand for the fork/join construct in 06-187 (use SELECT CASE inside DO CONCURRENT), but a prettier syntax for fork/join would be desirable. Fork/join might be too structured to provide the functionality desired for put-with-notify, but the asynchronous block described in 97-114r2 would not impose that structure. Both might be desirable. It is possible to develop one construct that provides both methods. Any of those proposals could provide the functionality of put-with-notify, copy_async, fine-grained local parallelism (e.g., pthreads), and asynchronous I/O. One mechanism instead of (at least) four. For unstructured parallelism, the completion event should be waited by the WAIT statement, not a new statement. Move the description of the WAIT statement from clause 9 to clause 8, and stop describing it as an I/O statement. There has already been discussion that we ought to do "something" about pthreads. I consider it undesirable to specify a standard interface to pthreads, since that mechanism is not the only one to attack the fine-grain parallelism problem. This is just as undesirable as a standard interface to MPI instead of coarrays. The argument is essentially the same as for coarrays: hide the details behind syntax, and let the processor decide (perhaps dynamically) how to satisfy the standard's abstract requirements. I advocated in 08-204 to use data transfer statements for inter-program communication, since coarrays are only for intra-program communication. The argument is again the same as for coarrays: Hide the details behind syntax, and let the processor decide (perhaps dynamically) how to satisfy the standard's abstract requirements. Had we adopted the asynchronous blocks advocated in 97-114r2, we wouldn't have needed asynchronous I/O with its attendant problems, and we wouldn't be having the present discussion of put-with-notify and copy_async, and contemplating what to "do" about pthreads. I.e., we'd already have the solutions in hand. Had we adopted the inter-program data transfer method based on I/O in 08-204, and advocated obliquely in section 17.3 of 97-114r2, there wouldn't have been near as much urgency for TYPE(*) and DIMENSION(..), since those were primarily developed to support MPI. Can we attack these problems in a coherent coordinated way, instead of adding a screw here, a rivet there, some bubble gum somewhere else, a paper clip, some duct tape...? The alternative is to preserve the "beloved Fortran tacked-on look" that was lamented during Fortran 90 development.