Enhancement: Provide contiguous variants

[zbeekman]

This relates to #2.

OK, I'm opening this anyway even though further investigation indicated that a change between Fortran 2008 and 2018 renders my idea pointless, as far as I can tell.

In Fortran 2008 the contiguous attribute of assumed shape dummy arguments could be used to enforce they were argument associated with contiguous actual arguments and prevent copies. Fortran 2018 however, dictates that non-contiguous actual arguments will be copied into local contiguous arrays. For very complex and high AI/OI (operations per byte) workloads this copy would be beneficial and prevent subsequent copies. But the whole reason assumed shape dummy arguments are usually slow is because the compiler is creating array temporaries.

AFAICT, as of Fortran 2018, there is no point putting the contiguous attribute on dummy arrays unless you know that you want to enforce a local copy in the event that the array is not contiguous. A discussion of the change in the standard can be found here: https://stackoverflow.com/questions/47852648/passing-non-contiguous-argument-to-contiguous-dummy-array-in-a-fortran-procecdue

FYI: @afanfa @rouson

[milancurcic]

Is the proposal here to add an implementation for each specific function in FF that uses contiguous attribute for input arguments?

Perhaps I misunderstand the usefulness of it, but on first look it seems like a micro-optimization that would considerably increase the size of the source code and uglify the API. Does the benefit outweigh the cost?

In general, I prefer writing simpler and more general code and let compilers decide how best to evaluate the function. I think adding contiguous would go against this. A good compiler should be able to make a decision when to make local copy of the array. Perhaps I assume too much.

[zbeekman]

Is the proposal here to add an implementation for each specific function in FF that uses contiguous attribute for input arguments?

Yes, but I was basing this idea off of the notion that contiguous would prevent copies. The F2018 standard seems to make it so that it is more likely to create a copy when using contiguous.

The only possible case where I could see this being useful is if you have highly nested/recursive calls. Then on entry the dummy arguments will be contiguous and the compiler should be able to reason that child calls with array actual arguments are all also contiguous.

Perhaps I misunderstand the usefulness of it, but on first look it seems like a micro-optimization that would considerably increase the size of the source code and uglify the API. Does the benefit outweigh the cost?

Well, for the F2008 semantics I would argue yes: Array temp copies are super expensive. The old array passing syntax call my_sub(matrix, m, n) ends up being faster than assumed shape dummy arguments in a shockingly large number of cases, and by a shockingly large margin.

But, given the F2018 change, I would agree with you: This isn't worth the hassle, certainly not without benchmarking to prove that it makes a big difference, but I'm very skeptical. If the F2008 semantics held, things would be different.

In general, I prefer writing simpler and more general code and let compilers decide how best to evaluate the function. I think adding contiguous would go against this. A good compiler should be able to make a decision when to make local copy of the array. Perhaps I assume too much.

I agree. But, historically, it's been very hard for compilers to determine when they can safely avoid a copy due to language semantics. I'm hopeful that something else in the F2018 standard makes it easier for compilers to reason about when arrays are or are not contiguous, since they changed the semantics of the contiguous attribute.

I'm going to close this since there's not obvious path forward given the F2018 changes.