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 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1a44c40a66c293f3 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!newsfeed2.ip.tiscali.net!tiscali!newsfeed1.ip.tiscali.net!proxad.net!proxad.net!62.253.162.218.MISMATCH!news-in.ntli.net!newsrout1-win.ntli.net!ntli.net!news.highwinds-media.com!newspeer1-win.ntli.net!newsfe1-win.ntli.net.POSTED!53ab2750!not-for-mail From: "Dr. Adrian Wrigley" Subject: Re: PAR (Was: Embedded languages based on early Ada) User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: Newsgroups: comp.lang.ada References: <1172192349.419694.274670@k78g2000cwa.googlegroups.com> <1172239820.896603.222120@k78g2000cwa.googlegroups.com> <113ls6wugt43q$.cwaeexcj166j$.dlg@40tude.net> <1i3drcyut9aaw.isde6utlv6iq.dlg@40tude.net> <1c61jqeqo68w$.2irtg70stnsa.dlg@40tude.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 06 Mar 2007 13:18:50 GMT NNTP-Posting-Host: 82.21.99.109 X-Trace: newsfe1-win.ntli.net 1173187130 82.21.99.109 (Tue, 06 Mar 2007 13:18:50 GMT) NNTP-Posting-Date: Tue, 06 Mar 2007 13:18:50 GMT Organization: NTL Xref: g2news2.google.com comp.lang.ada:9720 Date: 2007-03-06T13:18:50+00:00 List-Id: On Tue, 06 Mar 2007 02:01:33 +0000, Dr. Adrian Wrigley wrote: Thank you for your intelligent input on this. Martin, Randy: I chose "par" and "all" simply because that reflects Occam and the previously suggested "for all" loop. "parallel" would make a lot of sense: parallel CookDinner; DoTaxReturn; BookHoliday; end; would allow execution in separate tasks, or sequential execution in any order. for I in Data'range parallel loop Transform (Data (I)); end loop; would allow reordered or concurrent loop execution. Ray: > I would strongly discourage this practice. Getting sequential programs > correct is hard enough. Parallel programs are vastly more difficult and > subtle. Sequential and parallel programs can easily exceed a programmer's analyitical limits and comprehension. Hardware designers are used to thinking about concurrent operation. Concurrency involving independent operating units without communication is often straightfoward. There is no communication to screw up - data are read in parallel and combined serially. This a very common and useful type. In my opinion, "par" and "seq" were technically successful in Occam, and many of the difficult and subtle problems are absent from the above code because the concurrent units *cannot* address each other. These parallel constructs are simpler and more restricted than Ada tasks. The point of "par" is that the restrictions eliminate concerns over control flow. The issue is checking for erroneous data flow (eg accidental concurrent updates). The compiler should warn when this appears to be a hazard. > It is only 2nd class because our brains our wired that way, at least in > terms of how we know how to program. But breaking down programs into sequential steps is a skill which has to be learned. So many other things have concurrency - mathematics, physics, hardware. > The point is to choose one way or the other, and to have the source be > clear about that decision. That is *almost* what I am saying. Mark the obviously concurrent bits as concurrent. Mark the rest as sequential. Assume the compiler will choose true concurrenct execution sensibly. tmoran: > If programmers think of "par" as "I've carefully analyzed > this algorithm and it may be run in parallel" that's good. If they > think of "par" as "I want you to run this in parallel", I think that > would be a bad mindset. Explicit Ada tasks are more like the latter. precisely my point. Writing code with "par" is a fairly simple transition from sequential coding. Once you've had a bit of practice, writing robust parallel code is pretty easy, and most blocks are clearly parallel or clearly not parallel. You need to pay a bit more attention to what is pure and what isn't. (much easier than tasks!) Randy: I'm a big fan of declaring functions as pure, and it is disappointing to me that Ada still can't do this. A function declared pure should permit reordering of invocation and memoization etc. It doesn't have to be pure, technically (I support the "user beware" version), but compilers should warn of impure behaviour - perhaps a pragma to reject impurity would help. Things like invocation counts or debugging statements usually break the purity of a function. I don't know how procedures should be addressed. The meta-compiler approach is interesting, and rather like what I suggested earlier about a new language, permiting fine-grain concurrency, suitable for hardware and software, similar to a rebranded/renamed Ada. The problem with an Ada intermediate is that you can't easily translate programs with "par" into a language without. There is no realistic work-around or simulation of the execution behaviour of par. Par says "create a thread if it looks appropriate at this moment". The expectation is that this generates the appropriate concurrent call instruction. Maybe some major compiler hacking and special directives could patch something together, like Cilk does for C. One aspect of this discussion is the inaccessability of fine-grain concurrency to either a harware developer or a software developer. As a processor designer, I can see how to implement concurrent calls and concurrent memory access - but doing this does not help run any existing code. As a programmer, I can see where my code is logically concurrent, but the language denies me this expressiveness, and my processor doesn't support it. Some leadership is needed! Thanks. -- Adrian