"Generic Dilemma" - Is it true? If truly yes, can Fortran go with "Slow Compilers"?

[FortranFan]

Design for a Generics facility in programming languages now appears to suffer from The Abundance Syndrome - The Problem of Plenty. There is just too much information out there on both the "theory" and "practice" of generic programming, too many ways to go about it.

It also appears language designers have unconsciously, subconsciously, or consciously faced a dilemma: to go with language design decisions that lead to

1. Slow programmers AND/OR
2. Slow processors (compilers) AND/OR
3. Slow run-time behavior (poor program execution times)

I personally think Fortran is mostly in camp 1 of above choices, with some limited Generic facilities it teases programmers who then end up spending a lot of time trying to work their way around the gaps and limitations in the language.

But then Fortran also includes the unlimited polymorphic - CLASS() and TYPE() - which teases the programmers even further and should they pursue unlimited polymorphism in Fortran as a "poor coders'" substitute for their needs in Generics, the resultant code will also suffer at run-time with dynamic typing and dispatch. This then falls under camp 3 also.

So, as a high level vision for any improved design Fortran pursues with Fortran 202Y and beyond, my recommendation will be to help the programmers first - for the practitioners of Fortran and their time are the most precious and valuable assets. And run-time performance is the next aspect of most interest to Fortran, it has long been an important distinguishing characteristic, to write the least.

Thus any design of Generics in Fortran should keep this in mind and if need be, place the onus during the feature design on the processors i.e., place it under camp 2 above.

[tclune]

Interesting post. I would add to you your list: 4. Slow emergence of support from vendors. This one is probably somewhat unique to Fortran in that there are few vendors and all have very limited budgets for implementing new features.

[certik]

Regarding slow compilers, I actually think if we go with the "strong concept" idea, as discussed at our last meeting:

https://fortran-lang.discourse.group/t/generics-proposal-for-202y-video-call/353/7?u=certik

it can be implemented in a way that compiles quickly, at least in Debug mode (e.g., by referring the resolution to runtime, thus being able to generate machine code right away for a generic subroutine). In Release mode one would do it at compile time, which would indeed be a bit slower, but hopefully not as slow as in C++ (which has "light concepts") because the compiler wouldn't need to examine the body of the generic subroutine every time; and in Release mode one applies all optimizations anyway (such as function inlining, which in some sense is very similar to generic programming).

[tclune]

I think one of the challenges that may affect vendor compilation speed is that of detecting related instantiations of the same template. If the compiler inlines and compiles the template at each instantiation that can be wasteful and end up with a bloated executable. My understanding is that, at least in the early days, some C++ implementations instead deferred the inlining until the link stage. The result was fast compilation followed by incredibly long link times as the various instantiations were cross referenced using a presumably sub-optimal algorithm. None of this should be inherently slow, but vendors will presumably focus on getting it "right" before the overly worry about going fast (both at compile time and at run time).

[certik]

I will try to have a prototype compiler implementation of the generics, which would help answer many of these questions.

[FortranFan]

@certik wrote Oct. 23, 2020 11:06 AM EDT:

I will try to have a prototype compiler implementation of the generics, which would help answer many of these questions.

Having a prototype compiler implementation will be of tremendous help, in fact it will be invaluable.

With Fortran standard, I end up spending a lot of time reading current and older papers by J3 and listening in to discussions. And I've been saddened to find a lot of good ideas and promising proposals that didn't get considered or pursued because they were viewed without actual evidence to be inefficient or too costly to implement. On the other hand, there have been features that have moved forward with the presumption all the details have been worked out on paper but which have been later discovered to have significant holes or issues following compiler implementations of the published standard e.g., FORALL with Fortran 95, finalization with Fortran 2003, and DO CONCURRENT with Fortran 2008.

Thus a prototype compiler implementation with Generics will be most welcome.

[FortranFan]

@tclune wrote Oct. 19, 2020 11:13 AM EDT:

.. I would add to you your list: 4. Slow emergence of support from vendors ..

Yes, but it's good to see some Fortran implementations really turn a corner in this regard e.g., Intel Fortran Beta of their latest oneAPI compiler toolset offers full Fortran 2018 support (though critical bugfixes in certain key areas are outstanding but I think that's a different matter).

My original post here is concerned more with design choices with the Generics feature: chances are the work, as it progresses on its way toward Fortran 202Y, will arrive at many a "fork in the road." I hope the path taken on each or most of such options will be those that which help programmers without sacrificing run-time execution.

I'm encouraged by the promise of "strong concepts".

[tclune]

I think it is safe to say that if it is perceived to harm run-time performance the feature will not be accepted. One of the main advantages of templates over run-time polymorphism should be to allow compilers to exploit type-specific issues during instantiation.