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!newsfeed00.sul.t-online.de!t-online.de!news.buerger.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: PAR (Was: Embedded languages based on early Ada) Date: Mon, 5 Mar 2007 21:30:28 -0600 Organization: Jacob's private Usenet server Message-ID: 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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1173151727 13584 69.95.181.76 (6 Mar 2007 03:28:47 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 6 Mar 2007 03:28:47 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Xref: g2news2.google.com comp.lang.ada:9704 Date: 2007-03-05T21:30:28-06:00 List-Id: "Dr. Adrian Wrigley" wrote in message news:pan.2007.03.06.02.02.27.892793@linuxchip.demon.co.uk.uk.uk... ... > PAR is about indicating in the source code which statement sequences > are unordered. The idea is to make the syntax for concurrency > as simple as the syntax for sequentality. Perhaps using "par" > instead of "begin" is the way to go. Adding "all" to the for > loop also makes a lot of sense. My $0.02 worth: One thing I'm absolutely certain of is that "par" would never, ever appear in Ada. That's because Ada keywords are always complete English words (that's true in the packages, too; abbreviations are frowned upon). I admit that "par" *is* an English word, but it doesn't have anything to do with parallel. So, I think the syntax would be more likely something like "begin in parallel" or the like. (Similarly, "all" in a for loop is just too small a keywork for such a major semantic change. I think I'd prefer "parallel" to be used somewhere in the loop syntax; but I could be proved wrong in this instance.) > If you can persuade programmers to use "par" unless they explicitly > *need* sequential execution, a great many statements will be marked > as concurrent. Numeric codes will use "par" in the computational > core, as well as outer layers of execution. Yes, and a great number of programs will have become unstable. That's because the default in Ada is for objects that are *not* safe to access in parallel. (That's a problem for Ada tasks, too.) Only objects with pragma Atomic and objects wrapped in protected objects can be assumed safe. I know you've said that you would expect programmers to worry about such things. But that's the C way of thinking about things, and that is the root of much of the unreliably of modern software. Programmers are likely to test their programs on some compiler and then assume that they are correct. But when dealing with parallel execution, nothing could be further from the truth. The next compiler or OS will make the program execute completely differently. The only way to "test" these things is to have tools that enforce proper behavior (no access to global objects without synchronization, for instance). Of course, there is no problem with purely independent subprograms. The problem is that hardly anything is purely independent, even most independent algorithms depend on shared data (like a database) to guide their execution, and if something else is changing that data, there is a lot of potential for trouble. ... > Mandating sequential execution except where the "pragma" is used > puts parallel statements at an immediate disadvantage - it makes > them seem to be second class citizens, added on afterwards > in an attempt to speed things up. Par should be "everywhere", it's > a *basic* component of program semantics - like a loop or a function call. > It's absent from programming languages is because processors can't really > take advantage of it at present, and text is inherently linear, needing no > special "seq" directive. Graphical languages on the other hand often > imply concurrency automatically, and so have the opposite property. "par" > is not a hint. > > Enough ranting for now... Darn, you were just getting interesting. ;-) $0.02 cents. Ada has the needed building blocks for parallel execution, given that it has defined what is and is not accessible in parallel. Most other programming languages have never thought of that, or found it too hard, or just don't care. But you also need enforcement of safe access to global objects (global here means anything outside of the subprograms that were called in parallel). I don't think that that would be very practical in Ada; the result would be pretty incompatible. (Maybe you could have procedures defined to allow parallel execution, sort of like a pure function, but it sounds messy. And we've never had the will to properly define Pure functions, either, that's because we couldn't decide between the "declared Pure and user beware" and "defined and checked Pure" approaches). What really would make sense would be a meta-compiler, that took source code in an Ada-like language with "begin in parallel" and other needed constructs and converted that to regular Ada code. (Parallel calls would turn into tasks, appropriate checking would occur, etc.). But the majority of the code would simply get rewritten into Ada - and then an Ada compiler could compile it. Such a system would be free of Ada compatibility concerns, but wouldn't necessarily have to give up much of Ada's power. (And, if it caught on, the Ada step could be dropped completely.) Clearly, the meta-compiler would have to know something about the target (how many threads are reasonable, for instance), but not necessarily a lot. Such a system could be a lot safer than Ada is (well, at least until you have to make a call to C...), especially for parallel execution. Randy Brukardt.