[gmx-developers] C++ in kernels

[Mark Abraham]

On Sat, Jan 11, 2014 at 5:01 PM, Erik Lindahl <erik.lindahl at scilifelab.se>wrote:

> Hi,
>
> On 11 Jan 2014, at 15:45, David van der Spoel <spoel at xray.bmc.uu.se>
> wrote:
>
>
> For the future we should become even more stringent on new code. I
> propose to also prevent new C code from going into the mdrun part of the
> code, at least past release of 5.0. Only by forcing all developers to
> make the switch can we get a broader developer base for future coding.
>
>
> When it comes to new modules I fully agree. We should also get better at
> replacing old modules (well, starting with modularizing stuff), but I think
> it’s better to keep _old_ code and patches to it C so we properly clean up
> and modularize as we advance, rather than having a gigantic unstructured
> mix of C and C++ code in all files.
>

Depending what you mean by "old code", that may not be workable. Anywhere
we want to use task parallelism is going to have to be compiled as C++,
e.g. because TBB requires it. The tasks themselves can be calling "old C"
code (e.g. actual kernels), of course. I think that anywhere we use OpenMP
has already volunteered for being compiled as C++ in the near future,
because it's the performance-critical code we need to work on. PME and
NBNXN stuff that is not actually a kernel, I'm looking at you!

"Old code" such as things we don't care about or plan to throw out at some
point seems likely to stay C until someone cares / it dies. Group kernels,
I'm looking at you! :-)

I do like David's suggestion to require some language-level discipline
about future changes to mdrun. Making that a workable policy requires that
a whole lot more code compiles as C++, which was anyway on my "to do right
after 5.0 releases" list. I want to move away from content like do_md()
being littered with C and preprocessor conditionality. We have the ongoing
need to implement algorithms in the face of huge configure- and run-time
flexibility, which is a natural fit for the Strategy design pattern. (In
September, I had plans to get started on this, which I deferred for some
hoped-for changes from Michael, which unfortunately didn't happen.) That
all combines naturally.

Of course, an mdrun bug fix should generally be a stylistic match with the
code that's around it.

There will be problems when (for example) people like Christian, Magnus or
 Carsten comes along with an otherwise useful, well-written and workable
feature like LJPME/TNG support/CompEl in gerrit recently/right now, but
which is not C++, perhaps with new data structures that do not even follow
C-style
http://www.gromacs.org/Developer_Zone/Programming_Guide/Encapsulation, etc.
If the code with which it might work can call C++, then we'd have to take
the hard line, no matter how much we like our friends ;-) If it can't call
C++, then probably it's a signal that it should get worked on... but right
now it seems there are too few hands to the wheel for all the unglamorous
heavy lifting that will need doing. I can live with that, but it will mean
a period of time of unknown length where someone with limited C++
background and/or not in Stockholm will basically have no chance of getting
anything accepted in GROMACS. I'd certainly like a month or so to actually
convert some existing code as examples, before we might really adopt such a
policy. We all need to learn a bit more, here.

So, to answer Roland's original question, STL vectors for NBNXN cluster
index lists seem like a good first step. The arrays get used in the kernel
functions, but the lengths are not, so passing in &vector[0] will be fine,
because of the std::vector guarantee of contiguity and the lack of need for
SIMD alignment. This would lead to bad performance only on an architecture
where the C++ compiler cannot do as good a job as the C compiler, even for
such a simple case. We have already accepted that this kind of thing could
happen sometime somewhere. We are not going to shed tears over it. We'll
only shed blood fixing it if it's g++ on x86, too ;-)

Cheers,

Mark


> 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-developersor send a mail to
> gmx-developers-request at gromacs.org.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140111/bb91ea62/attachment-0001.html>