<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 10, 2018 at 9:33 AM, Jed Brown <span dir="ltr"><<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">Mark Adams <<a href="mailto:mfadams@lbl.gov">mfadams@lbl.gov</a>> writes:<br>
<br>
> On Mon, Jul 9, 2018 at 7:19 PM Jeff Hammond <<a href="mailto:jeff.science@gmail.com">jeff.science@gmail.com</a>> wrote:<br>
><br>
>><br>
>><br>
>> On Mon, Jul 9, 2018 at 7:38 AM, Mark Adams <<a href="mailto:mfadams@lbl.gov">mfadams@lbl.gov</a>> wrote:<br>
>><br>
>>> I agree with Matt's comment and let me add (somewhat redundantly)<br>
>>><br>
>>><br>
>>>> This isn't how you'd write MPI, is it?  No, you'd figure out how to<br>
>>>> decompose your data properly to exploit locality and then implement an<br>
>>>> algorithm that minimizes communication and synchronization.  Do that with<br>
>>>> OpenMP.<br>
>>>><br>
>>><br>
>>> I have never seen a DOE app that does this correct, get you data model<br>
>>> figured out first, then implement.<br>
>>><br>
>><br>
>> Chris Kerr's weather code (GFDL Hiram) has a single OpenMP parallel<br>
>> region.  He was at the last NERSC workshop I attended.  You should talk to<br>
>> him.<br>
>><br>
>><br>
> He is the last person I need to talk to :) but I wish my fusion colleagues<br>
> had walked down the road and talked with him 10 years ago.<br>
<br>
</div></div>I don't know if Chris has ever lived there.  And he's great, but GFDL is<br>
an application, not a library.<br>
<br>
Jeff, let us know when MKL can be called collectively from within an omp<br>
parallel region.<br>
</blockquote></div><br>It can be called like that already, although I expect it to serialize by default to avoid nested parallelism.  You can always do something like the following, which may benefit from KMP_HOT_TEAMS_MODE=1.</div><div class="gmail_extra"><br></div><div class="gmail_extra">mkl_foo_wrapper(ARGS)</div><div class="gmail_extra">{</div><div class="gmail_extra">  if (omp_in_parallel()) {</div><div class="gmail_extra">    #pragma omp master</div><div class="gmail_extra">    {</div><div class="gmail_extra">      mkl_set_num_threads(omp_get_num_threads());<br></div><div class="gmail_extra">      mkl_foo(ARGS);</div><div class="gmail_extra">    }</div><div class="gmail_extra">  } else {</div><div class="gmail_extra"><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">    mkl_foo(ARGS);</span><br></div><div class="gmail_extra">  }</div><div class="gmail_extra">}</div><div class="gmail_extra"><br></div><div class="gmail_extra">Of course, the right solution is for MKL to have entry points that don't create a parallel region.  We have discussed this but it's not clear how important it is.  What MKL functions would you like to support this interface?  "All of them" is not going to be productive for either of us.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Jeff<br clear="all"><div><br></div>-- <br><div class="gmail_signature">Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a></div>
</div></div>