From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Mar 18 09:53:27 2013 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 DCF55356D4E; Mon, 18 Mar 2013 09:53:27 +0100 (CET) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1406 seconds by postgrey-1.34 at www5.open-std.org; Mon, 18 Mar 2013 09:53:26 CET Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id 371EF356899 for ; Mon, 18 Mar 2013 09:53:25 +0100 (CET) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id r2I8To64088535 for ; Mon, 18 Mar 2013 08:29:57 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: From: "Malcolm Cohen" To: "WG5" References: <20130308120458.DEF90356DB5@www.open-std.org> In-Reply-To: <20130308120458.DEF90356DB5@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4924) WG5 ballot on first draft TS 18508, Additional Parallel Features in Fortran Date: Mon, 18 Mar 2013 17:29:53 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk >Please answer the following question "Is N1967 ready for forwarding to >SC22 as the DTS?" in one of these ways. > 3) No, for the following reasons. It would be slightly nicer if the text describing the features indicated whether certain things were or were not image control statements. I understand that this would complicate the edits, but perhaps there could be an overview at an earlier stage. It seems to be possible to copy event variables by argument association, e.g. CALL sub(event,(event)) This should probably be prevented by requiring INTENT(INOUT) on event dummy arguments. 6.4 says "If the count of a event variable increases through the execution of an EVENT POST statement on image M and later decreases through the execution of an EVENT WAIT statement on image T, the segments preceding the EVENT POST statement on image M precede the segments following the EVENT WAIT statement on image T." which is all very well, but the very definition of "later" can only be interpreted as have segments already ordered, i.e. it is assuming a stronger fact than the result that it requires. Consider image 1 segment i does POST EVENT(x) image 2 segment j does POST EVENT(x) image 3 segment k does WAIT EVENT(x) for unordered segments i, j, k; then image 3 segment k+1 follows image 1 segment i or image 2 segment j, but which? Both? Neither? One of them but no-one knows which? The obvious semantics would be that it follows both, but that i,i+1,j,j+1,k are all unordered. That is, if the event counter has value N, posted by segments ii(1) to ii(N), then image k+1 follows all of ii(1) to ii(N). Obviously this needs to be rewritten to avoid assuming linear time ("later" forsooth) and to clarify the ordering that results. I would slightly prefer C605 to reworded as "An in an that is". Yes, it has the BNF rule number on it anyway, but we have gotten that wrong so often in the past that it is best to spend the ink to make it more readable. 7.2 STAT para has "argument" twice and "variable" twice. Please be consistent. An "unsuccssful" collective with no STAT= does not cause error termination. Why? If STAT_STOPPED_IMAGE is good enough to terminate SYNC ALL, it should be good enough to terminate a CO_BROADCAST. Why permit STAT to be present on some images and not others? Are there any error conditions for collectives apart from FAILED/STOPPED image? I see nothing about this being processor dependent. If there are possible error conditions, the draft requires the processor to compute the correct result and perform the correct action regardless ... surely some mistake. The stated design goal for performance is that collectives are not required "wait" for completion, except on the image receiving the result. However, if there are error conditions, presence of STAT (and maybe ERRMSG) will surely force such a wait to occur. It seems unsatisfactory to have go-faster features that don't work if one uses the reliability features. CO_BROADCAST does not require the same type parameters for SOURCE on all images. Also, VARIABLE would be a better name than SOURCE since it is INTENT(INOUT) and receives the result. CO_MAX of a scalar does not require the same type parameters for SOURCE on all images. It is unsatisfactory for CO_MAX et al to require the SOURCE to be a definable variable, thus preventing collective max/sum/etc. of INTENT(IN) or PROTECTED variables (or indeed, of expressions). If we can't have unambiguous syntax that handles both inplace collectives and result collectives, perhaps we should have two names, e.g. CO_SUM(SOURCE [ ,RESULT_IMAGE,STAT,ERRMSG ]) CO_SUM_RESULT(SOURCE,RESULT [ ,RESULT_IMAGE,STAT,ERRMSG ]) As specified, EVENT_QUERY seems completely useless in that one would not be permitted to use it from a segment that is unordered with respect to any EVENT POST statement that updates it. Indeed, events seem useless if there are multiple images that might want to post an event, since it would modify the variable from an unordered segment. Presumably events are meant to be excluded from the unordered modification rules, but I see no text that describes such semantics. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.