[gmx-developers] std::vector<Rvec> slowness

[Mark Abraham]

Hi,

On Wed, Mar 23, 2016 at 2:31 PM Peter Kasson <kasson at virginia.edu> wrote:

> Dumb question:  wouldn't smart pointers (C++11 std::shared_ptr be an
> intermediate solution between std::vector and old-school manual allocation?
>  (Not passing judgement on whether we should use std::vector<Rvec> but
> thinking about the options here).
>

Teemu's src/gromacs/utility/scoped_cptr.h is a useful bridge here, but
because it has a destructor, you can't put one in a struct that is managed
with snew - which is a problem common to std::vector and std smart
pointers. Fortunately C++11 permits a static assertion to be made about
this (and Teemu added it, and it has given me scars ;-) ).

So probably an intermediate strategy is to working on stopping snew being
involved with key mdrun data structures. One nice thing about C++11 is that
one can use

t_forcerec fr {};

to do value-initialization (ie for POD fields, zero them, which is
approximately what we do with calloc inside snew) rather than the
default-initialization of

t_forcerec fr;

which is one motivation for the

t_forcerec *fr;
snew(fr, 1);

used right now.

Then one has the option to put a smart whatever in a t_forcerec and the
destructor works so RAII works. Similar considerations apply to other data
structures, but I think a top-down approach is needed. Perhaps there are
issues with nested structs... I haven't thought about how the automatic
value-initialization of those works.

Mark

Best,
> --Peter
>
>
>> Date: Wed, 23 Mar 2016 13:18:52 +0000
>> From: Mark Abraham <mark.j.abraham at gmail.com>
>> To: gmx-developers at gromacs.org
>> Subject: Re: [gmx-developers] std::vector<Rvec> slowness
>> Message-ID:
>>         <
>> CAMNuMAT4GftoMf8t5uzB5o9E+CxFG2HEdi-JvbCDqukjXooY6w at mail.gmail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi,
>>
>> On Wed, Mar 23, 2016 at 1:56 PM Berk Hess <hess at kth.se> wrote:
>>
>> > Hi,
>> >
>> > It's impractical and bad for performance to go from AoS to SoA.
>> >
>>
>> Sure, but that's what we do every MD step on typical CPUs. We do DD
>> communication on XYZXYZXYZXYZ and then transpose them to XXXXYYYYZZZZ to
>> use in short-ranged kernels. If we did DD communication on
>> XXXXX....YYYYY..... ZZZZZZ.... then we still have gather-scatter overhead,
>> but we don't have transposition in the mix.
>>
>> The question is now if we can fix this issue or if we should always try to
>> > use .data() in inner-loops
>> >
>>
>> I think you're missing my point... we've always done a cast from rvec * to
>> real * to pass to inner loops. :-) Using data() is a similar idea - hence
>> my suggestion of as_real_array(theVectorOfRVecs).
>>
>> or if we should completely avoid std::vector<RVec> in performance
>> sensitive
>> > code and use good old C pointers with nasty manual allocation.
>> >
>>
>> Allocation is irrelevant to how one uses it. One must have a real * to be
>> sure the compiler isn't confused. To get that from a vector, we use
>> data().
>> Whether the allocation of the memory is managed by std::vector or snew is
>> immaterial.
>>
>> Mark
>>
> --
> 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/20160323/3c191eac/attachment-0002.html>