FINDLOC - Fortran 2008 intrinsic - when in Intel compiler?

[FortranFan]

Hi,

From what I can gather, there is no schedule yet to implement in Intel compiler the FINDLOC function, a Fortran 2008 intrinsic to find the location in array of an element with a particular value.  Is this true?  If yes, is it possible to encourage the decision makers in any way to take another look at this function, reinvestigate the user interest (if that would help), and add this to the development stack?

On a project I'm working on, there is a home-grown function (VALLOC) that is used extensively.  But it has some performance limitations.  Compared to test functions that are written in the same fashion as this home-grown VALLOC, MINLOC and MAXLOC intrinsics are about 10% faster on array sizes on the order of 1E6.  So I'm thinking FINDLOC may be similarly faster than VALLOC.  Hence our interest in getting the FINDLOC intrinsic added to an Intel compiler version in the near future.  Now, due to company policy, I'm unable to post any of the code.  However, I was hoping other users would also have a similar interest in FINDLOC.

For those of you who may not be familiar with the FINDLOC definition in Fortran 2008 standard, here is an excerpt from N1828 document at the WG5 link http://www.nag.co.uk/sc22wg5/links.html:

9.11 Find location in an array

The following transformational function has been added

findloc(array,value[,mask,kind,back]) or

findloc(array,value,dim[,mask,kind,back])

finds the location in array of an element with value value.

array is an array of intrinsic type.

value is a scalar of a type that may be used for intrinsic comparisons.

dim is a scalar integer.

mask conforms with array and is of type logical.

kind is a scalar constant expression.

back is a scalar logical.

This function is modelled on the transformational function maxloc, replacing the search for a maximum value with a search for the value value. The result has the type and kind of array and the shape is determined from the shape of mask and the value of dim or its absence, just as for maxloc. The search is applied to all the elements of array to yield a scalar or to the elements of each rank-one section that spans dimension dim to yield a result of rank reduced by one.

[TimP]

I submitted premier feature request 628822 on this issue nearly 2 years ago.  As ifort already supports auto-vectorization of linear search, this should be a valuable feature. ifort even supports an f95 work-around of the nature:

index = maxloc(merge(1.,0.,array == value),dim=1)

which does much the same thing in a more inscrutable way.  As the AVX ISA doesn't have suitable integer instructions, it's better to use default real for the implicit array.  For portability (this is a compiler breaker), you may wish to make an explicit temporary array, in which case ifort is able to fuse the loops so that it doesn't cost much.

I suppose in order to support any such f2008 intrinsics, the kind and mask arguments will have to be added to the f2003 ones, so it looks to me like a logical inclusion in an f2008 array intrinsics project.

With some compilers, the back feature can be achieved in f95 by specifying reversal of the array:

index = maxloc(merge(1.,0.,array(size(array):1:-1) == value),dim=1)

I don't think ifort could optimize this, but back might pose the same problem.

In principle, findloc should be more efficient than maxloc, as it would allow for early exit without the compiler recognizing such a specialized use of maxloc.

[Steven_L_Intel1]

We don't in general talk in public about timeframes for features, except for those which are almost certain to appear in the near future. FINDLOC is not among those, but it will get done eventually. We have decided to focus on finishing F2003, with some F2008 work around the edges. I will add your request to the list of those asking for FINDLOC.

[FortranFan]

TimP, Steve:

Thanks for your feedback and suggestions.

As you indicate, FINDLOC can be worked around with a specific use of MAXLOC/MINLOC.  And as can be seen, there are a lot of similarities amongst these functions and their parameters.

That is why I'm surprised FINDLOC is not already available in ifort when several other Fortran 2008 features have already been added.  I'd have thought FINDLOC was a "quickie", a low-hanging fruit, so to speak.  That is, a good developer could take the compiler code for MAXLOC/MINLOC and extend it fairly easily, relatively speaking of course, to achieve the FINDLOC functionality.  Anyways, thanks Steve, for adding one more user to list of folks asking for this function.

[Johannes_Rieke]

Hi all,

I like to warm up this old thread, because I recently could have used F2008th FINDLOC if it were available.

Are there any news regarding the implementation into the Intel Fortran Compilers? Have we reached the near future, Steve?

Best regards, Johannes

ps: Here is a more current thread on this topic: https://groups.google.com/forum/#!topic/comp.lang.fortran/LKpnqkIbYXY

[Steven_L_Intel1]

Not quite yet. Very likely in the major release happening in calendar year 2017 (not the "2017" product.)

[TimP]

Meanwhile, I use internal functions of that name to facilitate easy replacement when the time comes.

[TimP]

I got a notice from Premier Support confirming what Steve said above ("next major version").

[jimdempseyatthecove]

The newer instructions on KNC/KNL/AVX-512 that return results of vector cmp into __mmasknn registers should be quite useful for FINDLOC intrinsics.

Jim Dempsey

[TimP]

In the xe2018 beta compiler, there is some recognition of FINDLOC.  Perhaps I am mistaken in thinking that LOGICAL data types should be supported, or maybe I don't have the syntax right.

[Steve_Lionel]

Tim, this works for me - what are you trying?

    logical s(4)
    
    s = [.true.,.false.,.true.,.false.]
    print *, FINDLOC (s, VALUE=.false.)
    end

[TimP]

I should have recognized that the DIM=1 specifier is mandatory for my FINDLOC test cases (as it would be with the old MAXLOC substitution).  They all have some expression which evaluates to a logical array.

The cases all hit the "loop with multiple exits cannot be vectorized unless it meets search loop idiom criteria" diagnostic, which doesn't intervene if I replace findloc with an internal procedure written with a DO..exit loop.  In only one case (one with BACK=.true. and in effect a very short loop) is the lack of vectorization an improvement in performance.

Anyway, it does show that the beta FINDLOC implementation covers these cases, aside from the performance question.

[TimP]

Testing FINDLOC on the old Westmere linux showed 3 cases where FINDLOC showed performance at least equal to the previous best code in spite of throwing the message about not vectorizing due to multiple exits.

I couldn't find any support for MIC KNC in the beta ifort.

[Kevin_D_Intel]

The Beta 18.0 compilers only provide support for the Intel® Xeon Phi™ coprocessor x200 product family (formerly code named Knights Landing)