!standard 5.5.2 (2/3) 14-06-20 AI12-0119-1/00 !class Amendment 14-06-20 !status work item 14-06-20 !status received 14-06-17 !priority Medium !difficulty Hard !subject Parallel operations !summary ** TBD. !problem The increased presence of parallel computing platforms brings concerns to the general purpose domain that were previously prevalent only in the specific niche of high-performance computing. As parallel programming technologies become more prevalent in the form of new emerging programming languages and extensions of existing languages, safety concerns need to consider the paradigm shift from sequential to parallel behavior. Ada needs mechanisms whereby the compiler is given the necessary semantic information to enable the implicit and explicit parallelization of code. After all, the current Ada language only allows parallel execution when it is semantically neutral (see 1.1.4(18) and 11.6(3/3)) or explicitly in the code as a task. !proposal This proposal depends on the facilities for aspect Global (AI12-0079-1) and for aspect Potentially_Blocking (AI12-0026-1). ** Proposal TBD. !wording ** TBD. !discussion ** TBD. !ASIS ** TBD. !ACATS test ACATS B-Test and C-Test are needed for these features. !appendix From: Tucker Taft Sent: Tuesday, June 17, 2014 10:18 AM Here is the paper the "gang of 4" is submitting to HILT 2014 with a relatively detailed proposal for parallel programming in Ada 202x: http://bit.ly/parallada-gangof4 If there is time at the upcoming ARG meeting, some discussion and feedback from ARG members would be appreciated. **************************************************************** From: Randy Brukardt Sent: Tuesday, June 17, 2014 12:52 PM Are we going to get formal proposals for some/all of these features? For instance, we have an open AI on global in/out (AI12-0079-1) which is certainly more broadly applicable than just parallelism. There is also an AI for Potentially_Blocking, AI12-0026-1, misnamed "Task_Safe", which is useful for any program including tasking. In both of these cases, an important part of the proposals will be how they interact with predefined and language-defined subprograms. (If they're not specified for predefined "+", nothing useful could be done, for example.) As with all of these sorts of things, the devil is in the details. The basic ideas look fine, but we'll never really know without detailed proposals that can be tested against. **************************************************************** From: Tucker Taft Sent: Tuesday, June 17, 2014 1:54 PM True, but it is not worth making a more detailed proposal if the overall reaction is "yuck"! ;-) **************************************************************** From: Randy Brukardt Sent: Tuesday, June 17, 2014 3:10 PM Well, it looks great to me, but that's mainly because all of the details are missing. A lot of stuff looks great without the details (it's how modeling works, after all). The "yuck" only comes when the details are fleshed out... **************************************************************** From: Bob Duff Sent: Tuesday, June 17, 2014 5:52 PM Sounds like there are some good ideas in the paper, but I am very strongly opposed to ARG getting "detailed proposals" about how to do parallelism, or even wasting time discussing the matter. ARG should be moving more to the "standardize existing practise" way of doing. And that goes double for features whose ONLY purpose is efficiency -- such as parallelism. We (ARG) don't need detailed proposals in that area; we need an experimental implementation, and MEASUREMENTS of the efficiency of realistic programs. (And don't try to show me speedups of the recursive Fibonacci -- that's downright dishonest!) Until then, ARG should avoid wasting any time on the matter. Once we have proven practise, then ARG should take charge of standardizing it. My comments above don't apply so much to things like Globals, which are more about correctness/safety than efficiency. ARG could reasonably discuss Globals, although even there, an experimental implementation would be helpful. Regarding those: You can put Globals and Potentially_Blocking on a package. That's good. I think it should apply to child and nested packages of that package. I think you also want a way to give a default for Overlaps_Storage: "no overlaps unless specified, in this package and children". **************************************************************** From: Robert Dewar Sent: Wednesday, June 18, 2014 2:52 AM > Sounds like there are some good ideas in the paper, but I am very > strongly opposed to ARG getting "detailed proposals" about how to do > parallelism, or even wasting time discussing the matter. ARG should > be moving more to the "standardize existing practise" way of doing. > And that goes double for features whose ONLY purpose is efficiency -- > such as parallelism. I am in full agreement with this. At the last RTW, which I attended, I was struck by the fact that the RTW was debating removing some features in Annex D which no one has ever implemented, yet alone found useful in actual practice. The RM is not a research proposal :-) **************************************************************** From: Alan Burns Sent: Wednesday, June 18, 2014 5:59 AM The policy currently in Ada has been implemented by the Ada run-time from Santandar, and is supported in EDF operating systems (not Ada), though I agree these are mainly research and experimental platforms, not mainstream industrial platforms. **************************************************************** From: Robert Dewar Sent: Wednesday, June 18, 2014 10:39 AM But I am talking about the specific Ada features, which for sure have not been used by anyone in an Ada program :-) **************************************************************** From: Tucker Taft Sent: Wednesday, June 18, 2014 8:38 AM > The RM is not a research proposal :-) I agree that many language standards come after the fact, and are used to try to tame a wildly varying set of ad hoc extensions. That has never been the story with Ada. There are relatively few extensions (other than as packages, pragmas, or attributes) that Ada vendors or users try in any serious way, before the Ada Rapporteur Group begins to talk seriously about them. The ideal is that the ARG gets the ball rolling, indicates a direction we are serious about, and then vendors try prototyping the ideas, and then we come around to picking among the "serious" ideas based on prototyping results. I really don't see anyone beside the ARG being taken seriously at this point as a fountain for "ideas worth prototyping" (apologies to TED ;-). ****************************************************************