Re: Generators/coroutines in future Ada?

[Robert Eachus <rieachus@comcast.net>]

On Wednesday, July 12, 2017 at 6:47:19 PM UTC-4, Shark8 wrote:
> On Tuesday, July 11, 2017 at 11:35:19 PM UTC-6, Randy Brukardt wrote:
> > 
> > The coming problem with "classic" programming languages like Ada is that 
> > they don't map well to architectures with a lot of parallelism. The more 
> > constructs that require sequential execution, the worse that Ada programs 
> > will perform.
> 
 
> That's also why I'm also a bit dubious about the proposed PARALLEL / AND / END blocks: it seems to me that the mistake here is to delve too far into the minutia (the above "parallel assembly" idea) so as to make it difficult or impossible to automatically optimize parallel code because of the more low-level view imposed by the language... much like C's notion of arrays is fundamentally broken and undermines the benefits of C++.
> 
> Now, I admit I could very well be wrong here, but there's a gut-feeling that this is not the route we want to go down.

In the process of going down this rabbit hole from the back entrance...

Consider a very lightweight task construct like:

for parallel I in X'Range loop...end loop;

Obviously anything declared within the loop needs no protection (unless there are nested tasks). Similarly, reads of external variables need no protection as long as there are no updates during the existence of the loop.  Can these tasks call (heavyweight) tasks.  Sure, as long the reverse is not permitted. Note that you don't want to do this unless it is a single call with the correct answer.  (This needs some thinking about.  Maybe: for I in X'Range loop until Solved... with the semantics that no new threads will be spawned once Solved is set to true.) What about protected objects? Fine, as long as you realize that calling functions of a protected object are fine, but calls to procedures and entries of a protected object from within a parallel loop are likely to bring you down to single threaded speeds.  Atomic objects can be updated, but it seems best to have intrinsic operations which map to RMW cycles which have hardware support.  For example, a Max intrinsic: procedure Max(X,Y) assigns Y to X if Y is greater than X, otherwise does nothing.  Or a function Add(X,Y) that returns X+Y.  Or even an Add_One(X) that returns true if X becomes zero if that is all you have.

Again the direction I am coming at this from is how to create very lightweight threads that can use all of those CPU cores or GPU shaders out there.  When computing an array, you depend on the cache coherency and write pipes to insure that writes to a result array don't produce garbage.  If this means that threads must be merged (by hand or compiler) so that a complete cache line is written by one lightweight thread so be it.  For example, in matrix multiplication you might have to compute 4 or 8 entries in the result array from one thread.  Not a problem if it allows me to compute the result using all the CPU cores or shaders available without spending 90% of cycles in synchronization.

Would doing all this "right" require a lot of compiler support?  Sure.  But if that is what it takes, there will be (expensive) compilers for large machines, and compilers which recognize the syntax and translate it into standard Ada tasking.