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

Damian Rouson rouson at lbl.gov
Wed Mar 1 10:41:24 UTC 2023


This is sage advice.  I second every word.

Damian

On Tue, Feb 28, 2023 at 22:43 Jeff Larkin via J3 <j3 at mailman.j3-fortran.org>
wrote:

> 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/20230301/e6efd4fa/attachment-0001.htm>


More information about the J3 mailing list