[gmx-developers] C++ in kernels

[Erik Lindahl]

PS: Just to clarify - I’m certainly not saying “never”, just that we need to walk before we run, and that we need to have the present C++ tested in a real release before allowing it everywhere :-)

Cheers,

Erik

On 10 Jan 2014, at 22:47, Erik Lindahl <erik.lindahl at scilifelab.se> wrote:

> Hi,
> 
> Yes. Remember that after a lot of deliberation we agreed on a compromise to allow _very_ limited amounts of C++. This ended up being pushed to accept a lot more C++ (including Boost, exceptions, etc.). The decision we made about only allowing single templates also appear to have been broken rapidly...
> 
> Remember that most developers are not professional C++ programmers, and I’m a bit worried that large parts of the code are turning into pretty heavy C++. That might be a necessary evil (I _do_ realize it gives us lots of other features), but before moving this any further it is time to show that all the other C++ code we have is stable on all architectures, that it does not cause portability issues (for instance, that all the C++ compilers support SIMD instruction sets well enough), that it does not hurt performance, and that it works for the vast majority of developers. Remember that we still haven’t released any C++ version of Gromacs yet - 5.0 will be the big test there.
> 
> The question is not whether performance is fine for a vanilla compiler on Intel, but whether it is guaranteed not to suffer over 20 different architectures with lots of different compilers!
> 
> Cheers,
> 
> Erik
> 
> On 10 Jan 2014, at 22:21, Roland Schulz <roland at utk.edu> wrote:
> 
>> Hi,
>> 
>> is there any reason to limit C++ in performance critical code as long as it doesn't impact performance? So far it seems that C++ hasn't been used in any compute intensive functions so I wanted to check. Specially we would like to change the variable says arrays in e.g nbnxn_pairlist_t (those with _nalloc) to stl::vector. This would simplify the code and would it make it easier to copy the data for MIC offload. 
>> 
>> Roland
>> 
>> -- 
>> ORNL/UT Center for Molecular Biophysics cmb.ornl.gov
>> 865-241-1537, ORNL PO BOX 2008 MS6309
>> -- 
>> 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/20140110/d078460d/attachment-0001.html>