[gmx-developers] OpenACC Development

Erik Lindahl erik.lindahl at gmail.com
Fri Jul 1 19:21:27 CEST 2016


> 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.

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.

> 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.


Cheers,

Erik 


More information about the gromacs.org_gmx-developers mailing list