[J3] Self-assignment of allocatable component

[Vipul Parekh]

On Wed, Jul 28, 2021 at 11:43 PM Damian Rouson <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/20210729/e77e102c/attachment.htm>