!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 ;-). **************************************************************** From: Stephen Michell Sent: Sunday, June 22, 2014 10:24 PM Attached is a report that ARG requested from Brad, Tucker and myself in investigating how OpenMP could be used to implement Ada parallelism. For discussion at the ARG meeting this week. ----- Report to WG 9/ARG on the use of OpenMP for Parallelism in Ada Stephen Michell with contributions from Luis Miguel Pinho Brad Moore Tucker Taft Foreward At the ARG meeting November 2014, ideas were presented about ways to implement parallelism in Ada, and ways to interoperate with other language systems while using the multicore capabilities of modern computers. We were requested to investigate OpenMP from a technical perspective as well as a business perspective as a potential solution to implementing multicore parallelism in Ada. OpenMP Characteristics OpenMP is a set of libraries and language extensions that permit a user to access the capabilities of multicore systems from within certain languages - namely Fortran, C and C++. OpenMP's parallelism is "explicit parallelism" - i.e. all aspects of the parallelism are specified by compiler directives in the code that invoke library routines at the place of the directive through OpenMP API's. OpenMP lets the user specify code segments (usually "for loops", blocks and functions) that can be executed by threads (possibly operating on multiple cores) that are co-ordinated to implement an algorithm. The language extensions are converted into library calls to interact with a runtime to implement the algorithm. In trying to implement OpenMP on an Ada system, one would note that the concurrency model is quite different than Ada's. The "threads" that are created interact with other threads that use OpenMP primitives. This means that they will not interact with Ada tasks using Ada tasking primitives. For the interoperability with Fortran, C and C++ systems that are using OpenMP, an Ada OpenMP capability would be useful, whetehr or not it interacted with Ada tasks. This brings us to the business model. Business Model To implement An OpenMP for Ada, one must participate in the OpenMP community. One could develop compiler directives, either as aspects or pragmas and convert calls to meet the API, but to have it "standardized", one must be a full participant in the OpenMP group. One can participate in OpenMP as a university, as an individual or as a corporate participant. AdaCore was approached to see if they were interested in joining OpenMP (and paying fees), but declined. There is no point joining as individuals, as individuals cannot propose new language specifications for standardization. This leaves participation through a university. Barcelona Supercomputing Group is a participant, and Miguel Pinho has approached them about participating through Barcelona. Barcelona is receptive, but participation requires that Miguel find a PhD student willing to participate. To date there has been no final resolution. There is a GNU OpenMP binding (GOMP) that supports the GNU Fortran, C and C++ GNU compilers. Ada could define a thin binding to that interface. This would still leave the challenge of defining Ada syntax for the Open MP compiler directives and determining how such a library would interact with the Ada runtime (Tasking is not the only issue - elaboration issues are also a potential issue). Conclusion There are business reasons and technical reasons for creating an OpenMP Ada implementation. If an interface with OpenMP through Barcelona Supercomputing Group becomes possible, further exploration should happen. Otherwise, no further action in this area is anticipated. ****************************************************************