[gmx-developers] C++ in kernels

[David van der Spoel]

On 2014-01-11 10:24, Erik Lindahl wrote:
> HI Teemu!
>
> Email is always a bit dangerous/difficult when it comes to tone - sorry
> if it had too few smileys late a friday night ;-)
>
> My point wasn’t at all to critize the current C++ code, but to emphasize
> that we’ve been fine with introducing more C++ features than we
> originally planned, before saying that there are still some things at
> least I want us to wait with. You are probably right that the multiple
> templates are only in testing code - and I frequently have memory like a
> goldfish. Had I actually been troubled by a specific piece of code, you
> can trust that I would have complained on redmine.
>
> I don’t think the balance in our C/C++ transition is primarily a
> technical one (I’m sure C++ is fine technically for at _least_ 99.999%),
> but more social. We need to strike a balance between introducing enough
> C++ to make life easy and productive for C++ wizards, while limiting it
> enough so we don’t cause too much frustration and dropped productivity
> for non-C++-wizards (hey, that largely includes me :-). I think this
> means the balance will naturally move much more towards C++ as we go on,
> but we’ll need to let that take some time!
>
> Then the performance-sensitive routines are separate chapter. Post-5.0 I
> think we need come up with a better policy on what that really is, and
> try to limit it severely. Right now we have far too much
> hardware-specific code that is even more difficult to read than C++
> (e.g. SIMD), and finding ways to reduce this will give us more time to
> spend on the higher-level code - in particular C++ !
>
> Cheers,
>
> Erik
>
>
Just a few thoughts:

I have spend the last year (re)learning C++ (my first MD program was 
using Borland C++, 25 years ago :)), and I am really indebted to Teemu 
for comments to my code, and for providing great templates for 
developing further upon. That said I can not claim that I grasp all the 
detailed constructs that are in gromacs now.

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.


>
>
>
>
>
>
> On 11 Jan 2014, at 06:47, Teemu Murtola <teemu.murtola at gmail.com
> <mailto:teemu.murtola at gmail.com>> wrote:
>
>> Hello,
>>
>> I do understand your point about testing the C++ support before we use
>> it everywhere, and I don't disagree with that, but your tone just
>> prompts for a response for some of the details. ;)
>>
>> On Fri, Jan 10, 2014 at 11:47 PM, Erik Lindahl
>> <erik.lindahl at scilifelab.se <mailto:erik.lindahl at scilifelab.se>> wrote:
>>
>>     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.).
>>
>>
>> Of course it depends on how you view it (and how you define "amounts";
>> see below my comment on "heavy C++"), but vast majority of the C++
>> code is currently "simple", in the sense that it only uses very basic
>> C++ constructs (classes, yes, and some inheritance, and occasional
>> simple template).
>>
>> I remember the discussion on exceptions, and in the end everyone
>> seemed to agree that this would be the way to go.
>>
>> We _still_ don't require anything major from boost except for the
>> boost::exception support that we originally decided on (and the
>> dependencies it already brings with it, which is basically
>> boost::shared_ptr); the only thing added after that is
>> boost::scoped_ptr, and I have hard time believing that would be a
>> bottleneck for anything. By necessity, the use of exceptions requires
>> some usage of smart pointers throughout the code, but even this is
>> fairly limited.
>>
>>     The decision we made about only allowing single templates also
>>     appear to have been broken rapidly...
>>
>>
>> Could you perhaps elaborate? There is a _single_ instance of a
>> template with multiple parameters in the code (outside test code).
>> That particular template has been there from the start, and I remember
>> in 2010 explicitly showing _you_ the code and _specifically_ asking
>> whether this part was too complex. And you said no. The test code can
>> always be disabled, and doesn't affect the ability to compile mdrun or
>> its performance.
>>
>> Most other uses of templates are in specifying the contained type for
>> a container-like class, in very simple classes, or in individual
>> methods where they reduce the amount of boilerplate code the caller
>> needs to use, hopefully reducing the potential for bugs. There is no
>> partial specialization, there shouldn't be templated overloads with
>> non-trivial resolution rules, no SFINAE, no type traits, etc. If you
>> mean something else, please clarify.
>>
>> If you want to restrict passing templated types as template parameters
>> to other classes, then note that also, e.g., std::vector has multiple
>> template parameters, and the allocator itself (the second parameter,
>> which has a default value) is a template.
>>
>>     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++.
>>
>>
>> Again, this depends on your definition of "heavy". If you define it as
>> "over 10% of this source file would not compile with a C compiler",
>> then yes, but is that really the definition you want? As said above,
>> vast majority of the code only uses very basic C++ constructs, and I
>> would not call that "heavy", even though it is 100% C++, and not C.
>> And nearly all of the C++ code is documented, at least on some level,
>> which hopefully lowers the barrier. I'm willing to (and I hope other
>> people would be, too) to improve the documentation, but that would be
>> more efficient if others would actually specify what parts they would
>> like to have improved.
>>
>> My impression is that very few are really interested in (or maybe
>> rather, does not have the time to) actually discuss any details
>> related to C++, on the level that would lead to some concrete results.
>> In such an environment, if we had just waited to have a common
>> agreement on every single detail, with everyone explicitly voicing
>> that agreement, we (I) would probably not have written a single line
>> of code in the past 2-3 years… Maybe that would have been best for my
>> sanity, but it's hard to say where we would be if that were the case.
>> Since Gerrit came to use, I have simply pushed up small incremental
>> work, not trying to introduce any additional C++ features without a
>> very good reason (and those have been very few, and most have been
>> discussed at least in Redmine). I've yet to see a specific, concrete
>> complaint on where people would like to have "simpler" C++ or "less
>> heavy" C++.
>>
>> Just some (or maybe quite a few) thoughts,
>> Teemu
>> --
>> 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
>> <mailto:gmx-developers-request at gromacs.org>.
>
>
>


-- 
David van der Spoel, Ph.D., Professor of Biology
Dept. of Cell & Molec. Biol., Uppsala University.
Box 596, 75124 Uppsala, Sweden. Phone:	+46184714205.
spoel at xray.bmc.uu.se    http://folding.bmc.uu.se