OpenMP min/max reduction

[TimP]

A knowledgeable customer asked why there is no OpenMP min or max reduction for C, as there is for Fortran. I agreed this seems useful. If anyone has suggestions about this, it would help me in submitting a feature request. The main problem I see is the lack of a standard C operator equivalent, and the general C rather than C++ orientation of OpenMP, but now it appears a lot more esoteric C++ stuff is being coupled into OpenMP.

[Armando_Lazaro_Alami]

There are reference of use of min/max reductions in gcc 4.7 and up. See :

http://www.techdarting.com/2013/06/openmp-min-max-reduction-code.html

As in OpenMP 3.1 specification ( http://openmp.org/wp/2011/07/openmp-31-specification-released/ )

But  I do not use gcc, I only found the references in several sites some time ago.

[Armando_Lazaro_Alami]

Great to have support for min/max reduction as defined by OpenMP 3.1 and 4.0 !

Thanks !

[TimP]

The final 13.1 and subsequent intel compilers have full openmp 3.1 min/max reduction which works well. 15.0 beta performs well with some examples of omp simd max reduction.

[TimP]

icc and ifort 15.0.0  required stuff like

#if  __INTEL_COMPILER >= 1500

#pragma omp simd reduction(min: x)

....

to optimize a min reduction .

The icpc alternative of using std::min in place of if or ? is good but doesn't optimize with gcc (nor MSVC).

The options are expanded in 15.0.3 to where

          x= a[1];
#if defined _OPENMP && _OPENMP >= 201307
#pragma omp simd reduction(min: x)
#endif
          for(int i= 2; i<=n; ++i)
                 if(a < x)  x= a;

 optimizes ( with or without omp simd reduction).  Apparently, the _OPENMP macro has been updated to recognize the date of the OpenMP 4.0 standard.  The last documentation I saw said that Intel didn't plan a full OpenMP 4 implementation (at least not in 15.x updates) and thus the OpenMP 4 standard date would not be recognized (but OpenMP 4 is listed as a goal of 16.0 beta).

I don't know which 15.0 update introduced the new flexibility; it works the same in the 16.0 beta.

icc (and ifort) have corrected the hassles in getting optimized min|max reduction.

I stumbled on this when noticing that 16.0 beta introduced some max|min optimizations to Cilk(tm) Plus CEAN notation.

If I set -fp-model source and remove #pragma, opt-report says vectorization is disabled accordingly, but it doesn't  hurt performance as much as might be expected.  I don't see why this should disable vectorization, unless there is some odd problem with values differing by less than FLT_EPSILON not showing inequality in simd compare.  gcc doesn't optimize well without -ffast-math, and omp simd reduction helps only a little.

I was confused when digging up this old thread, as it didn't say which language forum it was attached to.