paper on OO performance with gfortran

[Damian Rouson]

> On Aug 11, 2015, at 3:58 AM, Paul Richard Thomas <paul.richard.thomas@gmail.com> wrote:
> 
> Dear Damian,
> 
> That is fascinating. The fact that g++ is issuing SMD instructions and
> gfortran is not is concerning. Funnily enough, I have just started
> looking into precisely this area and so will follow it up.

Performance analysis is very tricky business — particularly when language comparisons are involved, 
but I’m glad this sparked some thought and that you’re already addressing this issue.   I find
that most authors of such comparisons don’t write Fortran code that fully exploits the most
powerful idioms and they often miss some of the semantic of value of features.  For example,
I’ve seen the ability to define new operators dismissed as “syntactic sugar’ without accounting
for the requirement that operator arguments have the “intent(in)” attribute, which naturally lends
itself to writing PURE procedures, which in turn opens up optimization opportunities, including
easing the path to asynchronous parallel evaluation.

Furthermore, there are differences in the cultures around the languages that make the comparisons 
even more difficult.  For example, many important Fortran programs are self-contained, whereas
nearly any significant C++ program links to libraries that are not part of the language. 

> 
> Parameterized Derived Types are much, much more complicated to
> implement than I ever imagined.

At last week’s Fortran standards committee meeting, it was the consensus that PDTs were
much, much more complicated to implement than anyone ever imagined.  Would it make more
sense to knock out DTIO first?  At least then gfortran would only be missing one major feature
for Fortran 2008 compliance. :)

> Unexpectedly relative to my first
> thoughts, it is the KIND parameters that are troublesome because of
> the need to generate separate instances of the derived type for each
> value(s) of the KIND parameter(s), using the original declaration as a
> template. I am going to raise the question fairly soon as to how to
> name these instances.... Were there only LEN parameters,
> implementation would be very straight forward.

As someone with nearly zero experience with PDT, I can’t help but perceive the feature as
sucking up a lot of resources without delivering enough bang for the buck. The two most 
common criticisms I hear about Fortran are the lack of compiler support for the standards
and the lack of a generic programming facility.  PDTs feels like a cruel joke in that it effectively
bolsters both criticisms: it makes it very challenging for compiler developers to support the
standard and it doesn’t fully deliver what many users want in terms of generic programming. 
Nonetheless, it’s important and you are to be commended for taking up the charge.  I’ve always
been a fan of partial solutions on the way to full solutions.  If you can support LEN parameters
in a straightforward way, would it make sense to start with that?

Damian