[J3] [EXTERNAL] Re: Self-assignment of allocatable component

Sat Jul 31 22:30:29 UTC 2021

Sorry for the noise everyone.    I meant to be responding in a private exchange with Damian, but apparently did not read the subject line carefully before hitting reply …

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Saturday, July 31, 2021 at 5:12 PM
To: j3 <j3 at mailman.j3-fortran.org>, Vipul Parekh <parekhvs at gmail.com>
Cc: "Clune, Thomas L. (GSFC-6101)" <thomas.l.clune at nasa.gov>
Subject: Re: [J3] [EXTERNAL] Re: Self-assignment of allocatable component

Hi Damian,

I was being silly,  the moment I thought about this issue again during an idle moment, I immediately saw how one could do this through the pointer to the parent node.  The snippet below shows swapping a depth-2 node on the rhs with the depth-1 node on th elhs
TYPE :: node
     TYPE(node), ALLOCATABLE :: rhs, lhs
     INTEGER :: payload
END TYPE node

TYPE(node), TARGET :: root
TYPE(node), POINTER :: p

ALLOCATE(root%rhs);  root%rhs = 1
ALLOCATE(root%lhs); root%lhs = 2
ALLOCATE(root%rhs%rhs); root%rhs%rhs=3

p => root%rhs
call move_alloc(from=p%rhs, to=t) ! ALLOCATABLE component of target of pointer
call move_alloc(from=root%lhs, to p%rhs)
call move_alloc(from=t, to=root%lhs)

This works with intel 2021 and gfortran 10.3.   Unfortunately, the latest NAG does not support recursive allocatable types, so I probably cannot use this approach yet …

Cheers,

-          Tom

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Thursday, July 29, 2021 at 7:51 PM
To: Vipul Parekh <parekhvs at gmail.com>
Cc: Damian Rouson <damian at sourceryinstitute.org>, j3 <j3 at mailman.j3-fortran.org>
Subject: [EXTERNAL] Re: [J3] Self-assignment of allocatable component

Great points, Vidal, and likewise Steve.  These perspective are helpful.  In almost every case that I’ve seen pointers used, I came away with the sense that they were the appropriate choice in the given context so I agree that the benefit is well worth the cost.

Damian
Sent from my iPhone

On Jul 29, 2021, at 14:47, Vipul Parekh <parekhvs at gmail.com> wrote:

On Wed, Jul 28, 2021 at 11:43 PM Damian Rouson <damian at sourceryinstitute.org<mailto:damian at sourceryinstitute.org>> wrote:
As one measure of the cost and complexity associated with a feature, someday I would love to see a count or a percentage of the of the emails on this list in response to a question roughly equal to “Is this code standard-conforming?” for code that involves a pointer.  By the suggested measure, I nominate pointers for the single most expensive feature in the history of Fortran.  ..

Hi Damian,

Please note in my experience the *benefits* of adding new features, particularly to modernize the language, are underestimated to an even greater extent than costs.

The benefits with many of the introductions starting with Fortran 90 through 2018 have been absolutely priceless, the interest in FORTRAN otherwise would have been so minimal as to be inconsequential i.e., without these standard revisions and the feature introductions therein.

And that includes the POINTER attribute also starting Fortran 90 which is more like an ALIAS rather than a raw pointer a la C.

When I started in earnest with modern Fortran mid-2010s, the enterprise where I work had quite a few codebases toward engineering and technical computing in mixed mode i.e., legacy FORTRAN plus some Fortran 90.  Few of these remain in Fortran, the rest having migrated away to a host of other computing paradigms and languages.  One library app that remains with Fortran, where I have implemented extensive refactoring using features including Fortran 2018, has a compute-intensive section of the code where an OO design pattern involving a derived-type component with a POINTER attribute has proven a vital *enabler* in 2x improvement in performance compared to the earlier version in FORTRAN that was previously seen as reference benchmark.  There is a variant in the works with a language and processor other than Fortran that uses a different pattern which I am told will give *similar* or somewhat better performance and that will become the "production" version eventually due to management diktat.  But that's not the case yet and this other team has a challenge on their hands.  However the larger point here is the semantics with POINTER attribute in current standard made the Fortran code highly competitive in this one case.  Could this have followed a different pattern and achieved similar or better performance; the other team sure thinks so and I agree with them in principle - not just that, I think the different approach can be pursued with modern Fortran also.  But what was achieved with Fortran was all the budget allowed, the budget constraints didn't permit any luxury to pursue other options.  So even though I can't ascribe a $$ benefit to the Fortran feature in question, I see it as invaluable.

Moreover the discussions on this mailing list with "does this conform" inquiries appear relatively "low cost" and not too onerous in terms of frequency but with no real quantification of data so as to "read" much into support and maintenance costs.

I firmly believe any discourse on costs without an even stronger focus on benefits in any human endeavor is generally detrimental, especially in any scientific and technological domains.  And that applies to Fortran also because Fortran can be a crucial enabling tool and technology for all such endeavors.

Regards,
Vipul Parekh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20210731/44c3a969/attachment-0001.htm>