[J3] [EXTERNAL] Re: Comments on 23-146

[Van Snyder]

On Tue, 2023-02-28 at 08:16 +0000, Jeff Hammond via J3 wrote:

> 
> 
> 
> 
> The only citation Van has provided is a book that will cost me around
> €100 (
> https://www.cambridge.org/fi/academic/subjects/computer-science/programming-languages-and-applied-logic/concurrent-and-real-time-programming-ada
> ),
>  which I don’t intend to buy at this point.

I didn't buy "Concurrent and Real-Time programming in Ada." I borrowed
it from my employer's library. And I read it precisely because the
Fortran committees were pondering concurrent methods at the time.
Coarrays were originally designed for symmetric SPMD programming, but
one could see today's situation with multicore processors combined with
GPUs on the horizon. I wanted to learn from history, not repeat
mistakes. I advocated for asynchronous blocks in section 18 of 97-114.
After studying the arguments against them, and the existence of
alternatives, I stopped advocating for them.

Craig Rasmussen proposed a scheme to adapt coarrays for unsymmetric
architectures. I think he proposed it in the first Boulder meeting, but
it might have been in the second Delft meeting.


> When I look for more recent topical references, e.g. 
> https://dl.acm.org/doi/abs/10.1145/249100.249112 (attached), I see
> evidence that Ada 83 decisions were made without consideration
>  of parallel architectures, as indicated by the following quote from
> a 1988 paper:
> 
> 
> 
> 
> 
> "Though Ada is now available on many uniprocessor systems, there is
> still little experience with truly multiprocessor Ada
> implementations- This experience will grow rapidly in the near
> future, and it will probably prove the benefits of high
>  level language features for the developments of new methods that
> successfully exploit the possibilities of parallel architectures.”

That design decisions were made "without consideration of parallel
architectures" is just plain false. I was part of one of the invited
teams that evaluated the requirements documents -- strawman, woodenman,
tinman, ironman, and steelman -- in 1976. Concurrent and real-time
processing were part of the requirements, from the beginning.

Our team also evaluated the four language proposals that responded to
the Steelman requirements.  These were coded as red, blue, green, and
yellow to hide the proposers identities. Only green, which turned out
to be from Jean Ichibah at Honeywell-Bull CII,  came even close to
meeting the requirements. And the other three were just weird.

One of my small Ada projects was a simple compiler that I gave my
students as the starting point for their lab work (I also gave them a
Modula-2 version). Oddly, there is no need for concurrent or real-time
programming in a compiler. Indeed, there is no need for it in most
programs. In fact, I never used the multitasking features of Ada in any
of my many projects. And the performance of the codes was just fine.

> The authors - writing in 1997 - add:
> 
> 
> 
> 
> 
> The open question remains: why is Ada almost unused to develop
> parallel programs? We would like to suggest that the primary problem
> is related to the efficiency and performance issues. 

The "efficiency and performance issues" were exclusively in the
multitasking corners, not the serial parts. They were caused by the
tasking model in Ada 83, which might have come from Per Brinch Hansen's
Concurrent Pascal. Efficiency and performance issues were precisely the
reason the Ada community introduced Protected Variables in 2002, after
they studied asynchronous constructs and concluded they are too
dangerous. Protected variables are essentially coroutines, which have a
long history in concurrent and parallel programming.

The Mars Pathfinder lander software was written in C++. It would
occasionally lock up and its "heartbeat" monitor would automatically
reboot after about half an hour. The deadlock was caused by a priority
inversion involving the modem, caused precisely by unstructured
asynchronous processing. They just lived with it because they didn't
want to risk uploading new software to Mars for a mission that was
expected to last only 90 days. And the new software might well have had
another "asynchronous" mistake.

All the Cassini orbiter software was written in Ada. They had no such
problems.

"Those who refuse to learn the lessons of history are doomed to repeat
them."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20230228/ef31ec67/attachment.htm>