[gmx-developers] C++ in kernels

[Erik Lindahl]

Hi,

Sounds like an excellent plan ;-)

One idea: To avoid long discussions about impact of new constructs (which is likely to be a non-issue for >90% of the cases), but also avoid each individual having to run tests on lots of architecture, maybe we could (after 5.0) try to come down with a shortlist of C++ techniques we would like to use and try to create some simple standalone examples for these that we can benchmark? Then we can jointly test those on a wide range of target platforms (both for portability and performance), and if that just works (TM) we can go ahead and rely on it when we implement things in Gromacs.

Cheers,

Erik

On 11 Jan 2014, at 17:58, Mark Abraham <mark.j.abraham at gmail.com> wrote:

> 
> 
> 
> 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-developers or send a mail to gmx-developers-request at gromacs.org.
> 
> -- 
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20140113/20ec5e78/attachment.html>