OpenMP Face to Face meeting 2018-1

We have done a very good progress towards the future of the OpenMP 5.0 specification. We have discussed many issues and voted several tickets that finally have already been included in the specification (or will do in the short term).

Small changes and discussions are always present in an OpenMP F2F meeting. Just to highlight some of them: there were some clarifications on the behavior of the implicit memory flushes and new features to allow programmers to specify default memory ordering when using atomics; it was a small discussion about how Fortran 2008 will impact on the current specification (there will be a short list of 2008 features that will not be supported in OpenMP 5.0); and also how exceptions and IEEE arithmetic can be supported (according with the Fortran 2003 standard).

With respect to the SIMD construct there were some valuable improvements: the addition of the “if” clause and how the construct binds to the current region (nesting). A future requested feature will be the support of SIMD virtual functions. We also discussed scenarios in which it would be necessary to shut down the whole OpenMP library using an API routine or how to support C++ 11/14 range-based for loops within the standard. And regarding the traditional worksharing constructs we had already removed the restriction to allow only rectangular loops with the collapse clause in such a way that other known shapes, as a triangular iteration space, will also be valid.

Task subcommittee efforts were focused in improving the data locality for tasks. RWTH Aachen University comes with a very concise solution showing significant performance improvement using the affinity clause. This solution is originally based on previous work already presented in IWOMP 2016. It was also a long discussion with respect to how this new feature could be applied to a target construct, although it will not be considered at this time.

One of the main issues in the F2F, as it has been usual in the last meetings, is the discussion of the accelerator’s support. Most important topics were related to the use of pointers within the device, allowing teams outside the target region, mapping in the context of unified shared memory, reductions in target regions and the reverse offload (offloading more work from the device to other devices or the host). Also two new features were proposed in the context of accelerator support: the “requires” directive and a new meta-directive operator to specialize OpenMP constructs according with the type of device availability.

The tools subcommittee topics were focused on improving the current support. Minor changes in tools and debug sections with respect to: routine names, parameter types and return types; activation and deactivation of the profile instrumentation using internal control variables; use data structures already defined in the specification (instead of declaring new ones, when they are equivalent); and include new services to get the version of the runtime and the OpenMP API were some of the topics discussed during this session.

Regarding the interoperability issues we had some initial discussions about what the people expect from this particular topic in the future. The different ideas were grouped into different areas. First, those that contemplate aspects of interoperability that affects a single runtime system but including multiple compilers or languages (Fortran, C or C ++). Second, how OpenMP can interoperate with other runtimes executing within the same process. The management of the underlying resources is a desired feature due parallel components may own a resource for long period of time. Third, how to support asynchronous services and how they can be synchronized with OpenMP tasks. The INTERTWinE European project showed very encouraging results on taskifying MPI communication services within an OpenMP program. This interface works with a routine-only approach, requiring no new pragmas/constructs. It was also mentioned the efforts in using threads in new MPI approaches (including end-points and fine-points based on qthreads).

So in summary, it has been a very productive week in which important advances have been made that will surely improve the OpenMP 5.0 support. Now we just have to continue working on the issues still open to have a first version (draft) for May of this year. See you in Bordeaux.