[gmx-developers] OpenACC Development

[Millad Ghane]

>
>> On 01 Jul 2016, at 19:09, Millad Ghane <mghane at cs.uh.edu> wrote:
>>
>> Thanks Erik for your reply too.
>>
>> Just two quick things:
>>
>> 1- I wasn't planning to propose a universal model for every architecture
>> (CPU, GPU, Xeon PHI) by OpenACC. I was looking into replacing CUDA
>> kernels
>> with OpenACC ones. My goal was to replace mostly any CUDA codes with
>> OpenACC (or even make them co-exist with each other).
>>
>> 2- I have to report back to my supervisor. So, my question is to you
>> (she
>> might ask me) is that: did you tried to port the code to OpenACC and
>> then
>> found out that it is not a good fit? Or, you are saying it is not good
>> based on your experience?
>
> The whole point of OpenACC is that it’s a compromise: It’s less
> efficient than CUDA, but also much less work to implement.

Right. Exactly.

>
> This far, I have NEVER seen an OpenACC implementation beat a serious CUDA
> implementation (although the latter is of course *MUCH* more work).
> Historically there have been a couple of centers that had the idea it
> would be great with OpenACC instead… and then we never hear from them.

Exactly. Maybe they are focusing on the readability and portability of
their code.

>
>> BTW, I totally agree (and have experience) with the fact that writing
>> low-level code is so much profitable, productive, and close-to-optimal
>> compared to a writing a high-level code, but the code loses its
>> portability (the fact is that low-level codes are close to hardware than
>> high-level ones). That's why some of these compilers advertise that they
>> are produce close-to-architecture codes and they suggest that it is
>> better
>> to rely on us and write codes using high-level languages!
>
> Right. That’s why Intel Itanium and Xeon Phi have been such smashing
> successes, while almost no programs use CUDA - not :-)
>
>
> Before believing what the compiler vendors say, I would advise to test
> their claims. Today, the only compiler that implements OpenACC well is the
> commercial PGI.
> If you read our installation instructions, you’ll see that we have found
> the performance so horribly bad on CPU code that we actively recommend
> against it.

Yeah. I've seen it. Not only in README files, but also in CMake files.
Whenever I change the compiler to PGI using "ccmake", it gives me a
warning that PGI compiler is a performance killer :)

However, as you said, the only compiler supporting OpenACC is PGI. That's
the reason I am focusing on PGI for the kernel parts. BTW, PGI is saying
that they are actually transforming the OpenACC API/Pragmas into CUDA
code. So, practically, there shouldn't be much more performance loss on
GPU part.


Thanks for your time,
Millad


>
>
> Cheers,
>
> Erik
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers or
> send a mail to gmx-developers-request at gromacs.org.