[J3] Performance Portability and Fortran: Making Fortran cool again

[Ondřej Čertík]

On Thu, Jan 17, 2019, at 9:21 AM, Tom Clune via J3 wrote:
> A colleague just shared a link that seems relevant to one of the 
> subthreads of this discussion:
> 
> https://www.nextplatform.com/2019/01/16/burying-the-openmp-versus-openacc-hatchet/
> 
> Note - I think the author has stated things exactly backwards in 
> several places, but I think the committee will generally like the 
> conclusion at the end.


This is a very good article, thanks for sharing it. I am wondering which things you think are stated backwards?

I discussed the "do concurrent" approach with several people at work and we arrived at the same conclusion as this article, that the compiler should simply offload "do concurrent" to a GPU and the GPU specific options that you currently specify in the OpenACC pragma, such as:

!$acc kernels loop gang(32), vector(16)

should become compiler options, that the user specifies when compiling for a given GPU. This is equivalent to how Kokkos works: you specify these options at configure time, they are not part of the source code.

This answers my question for an email above how it should be designed.

Ondrej