CVS difference for ai05s/ai05-0171-1.txt

Differences between 1.8 and version 1.9
Log of other versions for file ai05s/ai05-0171-1.txt

--- ai05s/ai05-0171-1.txt	2011/06/20 04:55:17	1.8
+++ ai05s/ai05-0171-1.txt	2011/12/31 07:20:02	1.9
@@ -489,3 +489,220 @@
 
 ****************************************************************
 
+From: Brad Moore
+Sent: Sumday, February 20, 2011  7:03 AM
+
+I have a few suggestions regarding the System.Multiprocessors package that I
+think might be worth considering.
+
+1) Package Name
+   Multiprocessors is a bit of a mouthful, it strikes me that this
+   functionality is centered around parallelism capabilities. Would it make
+   sense to call this package System.Parallel instead?
+
+2) Synchronous_Barriers are really tied to parallelism also. It seems it would
+   make sense for this package to be a child of System.Parallel
+   (System.Multiprocessors) as in System.Parallel.Synchronous_Barriers.
+
+3) I see the Barrier_Limit defined in Synchronous_Barriers as something that
+   more generally can be thought of as a Worker_Count. Moreover, I see this type
+   being potentially being used in other parallelism packages that we might add
+   down the road for Ada 2017. I am wondering if it makes sense to define
+   Worker_Count as an implementation defined range in System.Parallel
+   (System.Multiprocessors), and then it would simplify the declarations in
+   System.Parallel.Synchronous_Barriers. The type for the Release_Threshold
+   discriminant in Synchronous_Barriers would be Worker_Count, which makes sense
+   to me.
+
+4) I have raised this point before, but I think now I have a better
+   understanding of the issue. The uses of Synchronous_Barriers that I have seen
+   are used in parallel algorithms that need to interleave some sequential
+   processing in the middle of parallel processing. To do this, two barrier
+   objects are needed. One to transistion from parallel processing to
+   sequential, and another to transition back from sequential to parallel. When
+   transitioning from parallel to sequential, that is when you need the Notified
+   parameter, because only one of the tasks will be continuing out of the
+   parallelism. That is the task that performs the sequential bit. However, when
+   you transition back from sequential to parallel, you dont need/want a
+   Notified parameter. All tasks will be continuing past that point. That is why
+   I say there should really be two different calls to
+   Synchronous_Barriers.Wait_For_Release. One that hasa notified parameter, and
+   one that doesn't. It strikes me that this would be a common usage for the
+   Synchronous_Barriers package. Forcing the use of a Notified parameter when it
+   isnt needed is annoying.
+
+****************************************************************
+
+From: Alan Burns
+Sent: Monday, February 21, 2011  5:20 AM
+
+> 1) Package Name
+> Multiprocessors is a bit of a mouthful, it strikes me that this functionality
+> is centered around parallelism capabilities. Would it make sense to call this
+> package System.Parallel instead?
+
+I disagree.
+
+There are different forms of parallel hardware (GPUs for example) , the
+facilities provided in the CPU and Dispatching Domain packages are to do with
+multiprocessors and multi-cores (and task based exploitation of such
+architectures). And hence the name System.Multiprocessors seems appropriate.
+
+I agree than the Synchronous_Barriers facilities are concerned with difference
+forms of parallelism and hence they do not necessarily fit within the
+System.Multiprocessors hierarchy.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Monday, February 21, 2011  7:05 AM
+
+My thoughts are that Parallel might be a better umbrella to cover a wider range
+of parallelism. I agree that Dispatching_Domains is a multicore-specific
+concept, but then that should be fairly well understood by users of that
+package, I would think. Parallel as a package name is an adjective that works
+nicely to describe the child packages.
+eg.
+Parallel.Dispatching_Domains
+Parallel.Synchronous_Barriers
+
+or possible future packages maybe for Ada 2017?
+
+Parallel.Iteration      -- facilities for parallel loops
+Parallel.Recursion   --  facilities for parallel recursion
+
+I see your point however about the type CPU, as that type is specifically
+referring to multicore CPU's , and wouldn't cover other CPU's in the system,
+such as GPU's, DSP's, etc. If that were a type defined in Parallel, then there
+might need to be a modification to the name to make it clear it is
+multicore-specific.
+
+Also as a slight refinement/improvement to what I proposed yesterday....
+
+I think system specific univeral integer constants for
+Max_CPUs and Max_Workers could be defined in a system
+package. (System.Multiprocessors?)
+
+Then Parallel could be defined as a child of Ada.  eg
+
+with System.Multiprocessors;
+package Ada.Parallel is
+  pragma Preelaborate (Parallel);
+
+  type Multicore_CPU_Range is range 0 .. System.Multiprocessors.Max_CPUs;
+  Not_A_Specific_CPU : constant CPU_Range := 0;
+
+  subtype Multicore_CPU is Multicore_CPU_Range 1 .. Multicore_CPU_Range'Last;
+
+  function Number_Of_CPUs return Multicore_CPU;
+
+  type Multicore_Worker_Count is range 0 .. System.Multiprocessors.Max_Workers;
+
+end Ada.Parallel;
+
+Parallel might also be a word that might draw more people to have a closer look
+at Ada.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March  9, 2011  11:41 PM
+
+>I have a few suggestions regarding the System.Multiprocessors package
+>that I think might be worth considering.
+
+We've finished work on that package; moreover, we just had a discussion about
+the name (ending January 31st). It is pointless to force yet another
+re-discussion of that again. [Editor's note: you can find that discussion
+filed in AI05-0167-1.]
+
+[The only reason that I'm answering this now is that you are an HoD, meaning
+that there is a significant chance that you'll bring it up again during NB
+review -- and that means I will have to write a response sooner or later, and
+sooner is better.]
+
+>1) Package Name
+>Multiprocessors is a bit of a mouthful, it strikes me that this
+>functionality is centered around parallelism capabilities. Would it
+>make sense to call this package System.Parallel instead?
+
+Alan answered this adequately. CPU is a multicore/multiprocessor idea.
+
+>My thoughts are that Parallel might be a better umbrella to cover a
+>wider range of parallelism.
+
+But we're not looking for an "umbrella". It is way too late for that; if such a
+package was a good idea, it should have been introduced in Ada 95 (when the
+other "umbrellas" were created).
+
+Ada itself is all about parallelism; we don't separate those features from the
+others; they're sprinkled throughout the standard.
+
+...
+>Parallel as a package name is an adjective that works nicely to
+>describe the child packages.
+>eg.
+>Parallel.Dispatching_Domains
+>Parallel.Synchronous_Barriers
+
+OK, but why should Synchronous_Barriers be under Parallel, and things like
+Synchronous_Task_Control and Dynamic_Priorities not be under Parallel??
+
+>or possible future packages maybe for Ada 2017?
+>	Parallel.Iteration      -- facilities for parallel loops
+>	Parallel.Recursion   --  facilities for parallel recursion
+
+These seem like very general things. OTOH, the other things are fairly
+specialized; people would rarely use them. (Hardly any programs need the
+Dispatching_Domain or even the CPU capabilities.)
+
+...
+>Parallel might also be a word that might draw more people to have a
+>closer look at Ada.
+
+Maybe, but Ada has *always* been about tasking. Besides, if we're going to do
+that, we should call the package "multicore", that's much more of a buzzword.
+
+>3) I see the Barrier_Limit defined in Synchronous_Barriers as something
+>   that more generally can be thought of as a Worker_Count. Moreover, I
+>   see this type being potentially being used in other
+>   parallelism packages that we might add down the road for Ada 2017.
+
+This sounds like a bad idea to me. Unless the operations actually interoperate,
+you would want separate subtypes as the limits are likely to depend on the
+underlying implementation. And there is no reason to think that barriers would
+have the same limit as some other parallelism features.
+
+If it does turn out to be valuable, it is easy to move compatibly (subtypes of
+Positive can be defined anywhere and will have the same semantics), so there is
+no urgency to change this now.
+
+****************************************************************
+
+From: Brad Moore
+Sent: Sunday, March 13, 2011  9:43 AM
+
+>> I have a few suggestions regarding the System.Multiprocessors package
+>> that I think might be worth considering.
+> We've finished work on that package; moreover, we just had a
+> discussion about the name (ending January 31st). It is pointless to
+> force yet another re-discussion of that again.
+Not sure I'd agree with it being pointless, if something new is being brought to
+the table.
+
+> [The only reason that I'm answering this now is that you are an HoD,
+> meaning that there is a significant chance that you'll bring it up
+> again during NB review -- and that means I will have to write a
+> response sooner or later, and sooner is better.]
+
+And thanks for your comments. I much prefer receiving them sooner rather than
+later. I threw the idea out there thinking that it might receive some traction.
+So far it hasn't received any, so that tells me it is not a good idea.
+
+> Ada itself is all about parallelism; we don't separate those features
+> from the others; they're sprinkled throughout the standard.
+
+Good point.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent