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

[Jeff Larkin]

This is well and good, but does ignore the advancements that have been made since that time. A sizeable number of Fortran programmers are already using asynchronous constructs today successfully by way of OpenACC and OpenMP. They do so because the realities of the hardware being used for modern scientific computing necessitates it. There is no evidence that this is likely to change and significant evidence that it’s unlikely to.

"Those who refuse to learn the lessons of history are doomed to repeat them."

Yes, and history books are rewritten all the time as our understanding changes. Just as archaeologists have made discoveries that have changed our understanding of the ancient world, computer scientists have developed new understandings of how to program to the realities of computer hardware. We learn from the past, but out understanding of it also evolves.

Look at the learnings of Ada83, but also C++, Fortran developers currently using OpenACC and OpenMP, and the dozens of other examples of languages and programming models that have been forced to build a solution to address asynchrony. We can’t assume that the solution will be simple, but we must begin with the assumption that it’s necessary and design a solution that addresses the necessity while maintaining something that’s both implementable and usable. If we start with the assumption that a solution is impossible because it was once deemed impossible, then we’re doing a disservice to our user base and ensuring the continued migration from Fortran to other solutions, whether that’s directives or other languages altogether.

“Why, sometimes I've believed as many as six impossible things before breakfast.” ― Lewis Carroll, Alice in Wonderland

-Jeff

From: J3 <j3-bounces at mailman.j3-fortran.org> On Behalf Of Van Snyder via J3
Sent: Tuesday, February 28, 2023 4:20 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org>
Cc: Van Snyder <van.snyder at sbcglobal.net>; Malcolm Cohen <malcolm at nag-j.co.jp>
Subject: Re: [J3] [EXTERNAL] Re: Comments on 23-146

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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.cambridge.org%2Ffi%2Facademic%2Fsubjects%2Fcomputer-science%2Fprogramming-languages-and-applied-logic%2Fconcurrent-and-real-time-programming-ada&data=05%7C01%7Cjlarkin%40nvidia.com%7Cfd1c81f9077b4384dfeb08db19d18ed9%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638132160064983647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=CBrsB%2B23IkK0g80ipQ15ve2tqtNxz%2F7%2BMlaVdO2aWks%3D&reserved=0>), 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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdl.acm.org%2Fdoi%2Fabs%2F10.1145%2F249100.249112&data=05%7C01%7Cjlarkin%40nvidia.com%7Cfd1c81f9077b4384dfeb08db19d18ed9%7C43083d15727340c1b7db39efd9ccc17a%7C0%7C0%7C638132160064983647%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qZFY4%2FbzyITace5uwveZhd7gGva51tRDoVf0FmwGI7c%3D&reserved=0> (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/e4afed09/attachment-0001.htm>