<div dir="ltr">Hi,<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Mar 23, 2016 at 2:31 PM Peter Kasson <<a href="mailto:kasson@virginia.edu">kasson@virginia.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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).</div></div></div></div></blockquote><div><br></div><div>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 ;-) ).</div><div><br></div><div>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</div><div><br></div><div>t_forcerec fr {};</div><div><br></div><div>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 </div><div><br></div><div>t_forcerec fr;</div><div><br></div><div>which is one motivation for the</div><div><br></div><div>t_forcerec *fr;</div><div>snew(fr, 1);</div><div><br></div><div>used right now.</div><div><br></div><div>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.</div><div><br></div><div>Mark</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Best,</div><div>--Peter</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Wed, 23 Mar 2016 13:18:52 +0000<br>
From: Mark Abraham <<a href="mailto:mark.j.abraham@gmail.com" target="_blank">mark.j.abraham@gmail.com</a>><br>
To: <a href="mailto:gmx-developers@gromacs.org" target="_blank">gmx-developers@gromacs.org</a><br>
Subject: Re: [gmx-developers] std::vector<Rvec> slowness<br>
Message-ID:<br>
<<a href="mailto:CAMNuMAT4GftoMf8t5uzB5o9E%2BCxFG2HEdi-JvbCDqukjXooY6w@mail.gmail.com" target="_blank">CAMNuMAT4GftoMf8t5uzB5o9E+CxFG2HEdi-JvbCDqukjXooY6w@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
On Wed, Mar 23, 2016 at 1:56 PM Berk Hess <<a href="mailto:hess@kth.se" target="_blank">hess@kth.se</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> It's impractical and bad for performance to go from AoS to SoA.<br>
><br>
<br>
Sure, but that's what we do every MD step on typical CPUs. We do DD<br>
communication on XYZXYZXYZXYZ and then transpose them to XXXXYYYYZZZZ to<br>
use in short-ranged kernels. If we did DD communication on<br>
XXXXX....YYYYY..... ZZZZZZ.... then we still have gather-scatter overhead,<br>
but we don't have transposition in the mix.<br>
<br>
The question is now if we can fix this issue or if we should always try to<br>
> use .data() in inner-loops<br>
><br>
<br>
I think you're missing my point... we've always done a cast from rvec * to<br>
real * to pass to inner loops. :-) Using data() is a similar idea - hence<br>
my suggestion of as_real_array(theVectorOfRVecs).<br>
<br>
or if we should completely avoid std::vector<RVec> in performance sensitive<br>
> code and use good old C pointers with nasty manual allocation.<br>
><br>
<br>
Allocation is irrelevant to how one uses it. One must have a real * to be<br>
sure the compiler isn't confused. To get that from a vector, we use data().<br>
Whether the allocation of the memory is managed by std::vector or snew is<br>
immaterial.<br>
<br>
Mark<br></blockquote></div></div></div>
--<br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.</blockquote></div></div>