[J3] Performance Portability and Fortran: Making Fortran cool again
Tom Clune
tlclune at gmail.com
Thu Jan 17 13:33:26 EST 2019
> On Jan 17, 2019, at 1:10 PM, Ondřej Čertík via J3 <j3 at mailman.j3-fortran.org> wrote:
>
>
>
> 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 guess I have always felt that _OpenMP_ is less prescriptive. Performance is lost precisely because the compiler is not very constrained by the hints from OpenMP. I have less experience with OpenACC and CUDA, but in those, one generally specifies additional details to prescribe the calculation. I suppose from a purely “what iteration is assigned to which thread”, OpenMP is more prescriptive, but that’s not generally the limiting factor in performance.
>
> 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.
No argument, except that the real challenge becomes the granularity at which offloading occurs. In most of the codes that I work with, the individual loops are not expensive enough to amortize the transfers.
Cheers,
- Tom
>
> Ondrej
More information about the J3
mailing list