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

[Peter Kasson]

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).

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20160323/8a92cdd7/attachment.html>