From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,LOTS_OF_MONEY autolearn=unavailable autolearn_force=no version=3.4.4 Path: border2.nntp.dca1.giganews.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!feeder.erje.net!eu.feeder.erje.net!gandalf.srv.welterde.de!news.jacob-sparre.dk!loke.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT and Tasklets Date: Mon, 22 Dec 2014 17:06:14 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <8277a521-7317-4839-b0b6-97f8155be1a4@googlegroups.com> <9e1d2b9f-1b97-4679-8eec-5ba75f3c357c@googlegroups.com> <478c81f9-5233-4ae1-a3eb-e67c4dbd0da1@googlegroups.com> <1r2ziulc78imb$.ad6zx5upic6s$.dlg@40tude.net> <1gfkkgi7ukoj3$.1pqtchynzp9rc$.dlg@40tude.net> NNTP-Posting-Host: rrsoftware.com X-Trace: loke.gir.dk 1419289574 4875 24.196.82.226 (22 Dec 2014 23:06:14 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Mon, 22 Dec 2014 23:06:14 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Xref: number.nntp.giganews.com comp.lang.ada:191504 Date: 2014-12-22T17:06:14-06:00 List-Id: "Brad Moore" wrote in message news:Wsilw.1234991$1s.181390@fx05.iad... > On 14-12-19 06:05 PM, Randy Brukardt wrote: ... >>> I think that the block should have explicit parameters, e.g. Total must >>> be >>> an in-out parameter of the block. The syntax should be similar to the >>> selective accept. Each arm must also have parameters, and only those and >>> of >>> the block must be visible within an arm. E.g. A, B must be parameters. >>> Nothing else should be visible. >> >> Interesting. This does sound like a better approach to me. (The whole >> reduction object idea seems to me to be the worst part of the parallel >> proposals -- something needs to be available, but that doesn't seem to be >> the way to do it.) >> >> OTOH, the syntax to specify such parameters doesn't seem natural. We >> surely >> don't want to force a parallel block or loop to be the only contents of a >> subprogram. ... > As for reduction. We haven't yet discussed reduction for parallel blocks. > It's not clear that we even need that, because in a parallel block, it > seems easy enough to declare separate variables, and then write the > reduction yourself. I was more reacting to the method of specfying reduction for parallel statements (I hadn't realized that it was only allowed for loops, that seems inconsistent to me, even if it is mostly necessary for the loop construct). The problem I have is that it is really hard to wrap one's mind around the idea of reduction objects and reduction operations and especially reduction identity value. I'd like to it be more able to be obvious from the code specified. (I.e., if Total is being added in the loop, then clearly it will be reduced that way.) But I'm quite willing to say I don't know how to do that (yet), thus "more thought needed". Clearly the reduction objects have to be identified to the compiler; it's unclear to me that more is needed. After all, how the reduction is done is clearly in the sequential code, can't the compiler extract that for parallel reduction? Randy.