<div dir="ltr">Hi,<div><br></div><div>Also, the setup is intended to allocate and first-touch memory on each OpenMP thread so that (particularly) the output buffers do not suffer from false sharing issues. This would be a problem with a naive approach to "make one list and split it over all cores."</div><div><br></div><div>Mark</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jul 8, 2015 at 1:08 AM Szilárd Páll <<a href="mailto:pall.szilard@gmail.com">pall.szilard@gmail.com</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><div>On Wed, Jul 8, 2015 at 12:39 AM, Sikandar Mashayak <span dir="ltr"><<a href="mailto:mashayak@votca.org" target="_blank">mashayak@votca.org</a>></span> wrote:<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi,<br><br></div></div></div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div>I am trying to understand how a SIMD-based kernel distributes the work across OpenMP threads. I found that, given n threads, n neighborlists are built, each OpenMP thread is assigned a neighborlist and for each neighborlist outer and inner loop computations are performed using SIMD instructions. <br><br></div></div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div>My question is, whether building n neibhorlists and assigning 1 list to each thread is same (from performance considerations) as creating 1 neighborlist and dividing i-clusters among n threads (nci/n per thread)?<br></div></div></div></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div></div></div></div></blockquote><div><br></div><div>Not exactly. Lists are of different length and when N lists are produced for N non-bonded compute tasks, the search tries to generated balanced work. Splitting using the simple static nci/N formula will give imbalanced chunks of work.</div><div><br></div><div>You never said what are you trying to accomplish, how are you going to use the single 4x4 list? You may be able to avoid some pitfalls by sharing the bigger picture.</div><div> </div><div><div><div>--<br>Szilárd</div></div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><br></div>Thanks,<br></div>Sikandar<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 30, 2015 at 1:57 PM, Sikandar Mashayak <span dir="ltr"><<a href="mailto:mashayak@votca.org" target="_blank">mashayak@votca.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><div><div>Thanks Szilard,<br><br></div>Yeah, I guess with some coding merging neighborlists into a single simple CPU-style list is possible. For now, I am manually setting number of neighborlist to 1 independent of openmp threads. <br><br></div>Thanks,<br></div>Sikandar<br></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 24, 2015 at 8:00 PM, Szilárd Páll <span dir="ltr"><<a href="mailto:pall.szilard@gmail.com" target="_blank">pall.szilard@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi,<br>
<br>
I think it should be supported if not out of the box, perhaps with<br>
small code changes. I know we have discussed decoupling the search<br>
form the force compute to allow executing them on different number of<br>
executors/tasks. Also, I'm not entirely sure if the implementation<br>
allows searchig on N tasks and merging simple CPU-style lists into a<br>
single list output.<br>
<br>
Try looking into the nbnxn_init_pairlist_set() function which gets<br>
passed a boolean that tells whether to combine lists or not.<br>
<br>
Note that you can control the number of tasks (=OpenMP threads) in<br>
different parts of the code through the gmx_omp module which reads<br>
environment variables in the form of GMX_*_NUM_THREADS.<br>
<br>
Cheers,<br>
--<br>
Szilárd<br>
<div><div><br>
<br>
On Thu, Jun 25, 2015 at 1:06 AM, Sikandar Mashayak <<a href="mailto:mashayak@votca.org" target="_blank">mashayak@votca.org</a>> wrote:<br>
> Hi,<br>
><br>
> I want to use pairlist with M = 4 and N = 4 i and j cluster sizes. I<br>
> understand, that with OpenMP threads enabled, gromacs builds ntomp, i.e.,<br>
> nthreads, neighborlists. I understand, for 8*8*8 kernel type, these<br>
> neighborlists are combined and superclusters are built.<br>
><br>
> I am wondering, is there a way to combine all the nthreads neighborlist into<br>
> one for simple 4*4 type neighborlist?<br>
><br>
> Thanks,<br>
> Sikandar<br>
><br>
</div></div><span><font color="#888888">> --<br>
> Gromacs Developers mailing list<br>
><br>
> * Please search the archive at<br>
> <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<br>
> 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<br>
> send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
--<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>.</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br>--<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>.<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>