OpenMP 4.0

Tim Prince n8tm@aol.com
Sun Sep 1 17:37:00 GMT 2013


On 08/29/2013 09:40 PM, Tim Prince wrote:
> On 8/29/2013 2:20 PM, Tobias Burnus wrote:
>> José Luis García Pallero wrote:
>>> I don't know if this is the correct place for this question, but I
>>> haven't found any mailing list on the GOMP webpage.
>>> The OpenMP 4.0 specifications were launched ten days ago. This new
>>> standard includes several interesting characteristics as SIMD and
>>> accelerators directives and error handling facilities. Is planned to
>>> add this new version of OpenMP to libgomp and, then, to GCC 4.9?
>>
>> Well, it takes a while until features are implemented - and the 
>> implementation work can only start after a specification/standard is 
>> sufficiently finished to not change in a major way.
>>
>> Having said that, there is a GCC branch called gomp-4_0-branch (see
>> http://gcc.gnu.org/svn.html), which is used for the on-going 
>> implementation. I think SIMD already partially works (with C/C++, not 
>> yet with Fortran).
>>
>> I believe that it is planed to support OpenMP 4 in GCC 4.9.
>>
>>
>> Tim Prince wrote
>>> OpenMP 4.0 simd facilities are related to Cilk(tm) Plus pragmas, for 
>>> which there is a gcc branch on git (although I haven't figured out 
>>> that stuff).
>>
>> As far as I gathered, Cilk+'s pragmas and OpenMP'pragmas are supposed 
>> to be handled identically. (I think there were some differences but 
>> they got resolved by changing Cilk+.) There are some Cilk+ branches, 
>> which aim at consolidating the effort with OpenMP. Actually, some 
>> Cilk+ patches has been submitted for inclusion - thus, expect more 
>> for this. (The submitted patches do not include SIMD as far as I 
>> know. The branches do support it.)
>
> There are distinctions in Intel compilers between Cilk(tm) Plus and 
> OpenMP 4.0.  For example, Cilk(tm) Plus expects use of simd 
> firstprivate lastprivate where appropriate, while OpenMP 4.0 doesn't 
> support those clauses, and depends on the compiler recognizing those 
> cases of omp simd private.
> Intel once talked of reconciling terminology (it seems unsatisfactory 
> to market Fortran directives as Cilk(tm) Plus).
> Intel takes Cilk(tm) Plus simd to require in-line simd instructions 
> rather than automatic replacement by the special memset/memcpy library 
> function calls, while the corresponding omp simd construct doesn't 
> inhibit those automatic replacements.  I guess gfortran et al. aren't 
> so likely to introduce these substitutions, so don't need a means to 
> control them.
>>
>>
>>> For example, I know of no one planning to implement user defined 
>>> reduction. Some talk about proposing a specific standard on indexed 
>>> min/max before deciding about user defined reductions.
>>
>> I think the gomp-4_0-branch already supports min/max since quite some 
>> time. (For C/C++; Fortran supports it already since older OpenMP 
>> specs.) Additionally, I believe that Jakub intents to implement 
>> user-defined reductions (UDR) and that he has already done some prep 
>> work on the branch. Ignoring "omp target", UDR seems to be the 
>> biggest new feature.
> C omp parallel reduction(min|max: ) was introduced in OpenMP 3.1 but I 
> didn't find any tests for it in the gcc 4.9 testsuite. Corresponding 
> omp simd reduction would not be so important for C++ if g++ could 
> optimize min/max with maxp[sd]/minp[sd] as gfortran and icpc do.  No  
> omp max|min reductions are likely in the Intel icc/icpc 14.0 releases 
> in a week or so, regardless of claims to support OpenMP 4.0.
>>
>> (Regarding "omp target" and other accelerator/GPU/hybrid-system 
>> support: I think there is quite some interest to get it working with 
>> GCC, however, it probably will take until 4.10 or longer.)
>>
>>
>>> Among my ulterior motives for asking is my attempt to write a book 
>>> centered on HPC development topics.
>>
>> That sounds interesting!
>>
>>
>> Tobias
>>
>> PS: Regarding SIMD, in GCC 4.9 itself, some basic support has already 
>> been merged a few days ago. However, it is not yet accessible from 
>> user code (no front-end support) and I have the impression the 
>> information is not yet used for optimization. But expect soon some 
>> support (possibly something like #pragma simd, #pragma vector for 
>> C/C++ and usage for DO CONCURRENT in Fortran) - but I don't know 
>> which pragma and when the support will be added.
> DO CONCURRENT needs a more satisfactory way to invoke omp parallel. A 
> limited facility (beyond current auto-parallelization) would not 
> appear in ifort until next year.  It seems too difficult to cover all 
> possibilities.  Auto-vectorization works well already (in gfortran, 
> for example).
>
>
I grabbed the gomp-4_0-branch, had to set --disable-werror to build 
it.   I found 2 cases in netlib vectors benchmark where #pragma omp simd 
brings gcc performance up to at least match icc.  I suppose it could do 
the same for gfortran when the omp simd directives become available.
Tim

-- 
Tim Prince



More information about the Gcc-help mailing list