<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 29, 2014 at 4:45 AM, Cownie, James H <span dir="ltr"><<a href="mailto:james.h.cownie@intel.com" target="_blank">james.h.cownie@intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1f497d">I don’t really understand what problem you are complaining about.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Verdana","sans-serif";color:#1f497d">Your numbers show clang-omp as the fastest implementation in all directly comparable cases. That doesn’t seem like something we want to change!</span></p>
</blockquote></div><br>I think the complaint is this: on Darwin, the scaling to 4 "processes" is worse than on Linux.</div><div class="gmail_extra"><br></div><div class="gmail_extra">However, the reason is stated already: Linux provides a *very* fast futex implementation. Darwin either doesn't provide it or iomp doesn't use it.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If Darwin provides a fast futex interface, then iomp should use it. That's a useful request. I don't know enough about Darwin to help investigate whether the OS has a futex interface exposed to userland.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If Darwin doesn't provide a futex interface, there is literally nothing we can do about that. You aren't going to match the scalability of a kernel-supported futex with something in userspace.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Anyways, I do agree that micro-optimizing mutex performance for something like openmp seems somewhat less important....</div></div>