<div dir="ltr">Steven,<div>     Have you filed a radar bug report with Apple on this?. There always is the remote possibility that this issue could be addressed in a future OS release.</div><div>            Jack</div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, May 29, 2014 at 1:30 PM, Steven Noonan <span dir="ltr"><<a href="mailto:steven@uplinklabs.net" target="_blank">steven@uplinklabs.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Darwin has a very weak notion of "affinity hints":<br>
<br>
<a href="https://developer.apple.com/library/mac/releasenotes/Performance/RN-AffinityAPI/" target="_blank">https://developer.apple.com/library/mac/releasenotes/Performance/RN-AffinityAPI/</a><br>
<br>
But it's so dumbed down (only a concept of distinct affinity "tags"<br>
based solely on L2 cache sharing) that it's pretty useless. I did some<br>
microbenchmarks with it to simulate an OpenMP workload with pinning,<br>
and as far as I'm able to tell, the Darwin kernel just ignores those<br>
hints and does whatever it pleases.<br>
<br>
On Thu, May 29, 2014 at 5:39 AM, Cownie, James H<br>
<div><div class="h5"><<a href="mailto:james.h.cownie@intel.com">james.h.cownie@intel.com</a>> wrote:<br>
> I think the complaint is this: on Darwin, the scaling to 4 "processes" is<br>
> worse than on Linux.<br>
><br>
> Four threads is small. The OpenMP runtime is tested scaling in the 200+<br>
> thread range for Xeon Phi, and on big-iron servers. We measure the scaling<br>
> of a variety of more interesting things there (such as SpecOMP).<br>
><br>
><br>
><br>
> Futexes are fast, but then so are our spin-locks. The difference is what<br>
> happens when the lock is contended (whether you enter the kernel or not, and<br>
> therefore allow the kernel to schedule something else onto the same HW<br>
> thread). That should make little difference in this case, since the machine<br>
> is not over-subscribed.<br>
><br>
><br>
><br>
> If Darwin provides a fast futex interface, then iomp should use it.<br>
><br>
> Darwin does not provide it, so we can’t use it J.<br>
><br>
><br>
><br>
> I’d guess that the issue here is more likely related to affinity choices<br>
> made by the operating system (whether it chooses to place threads as<br>
> hyper-threads on the same core, as threads in the same socket, or across<br>
> sockets) than details of the locking. I believe that Darwin also has no<br>
> specific support that would let us control that either…<br>
><br>
><br>
><br>
> -- Jim<br>
><br>
> James Cownie <<a href="mailto:james.h.cownie@intel.com">james.h.cownie@intel.com</a>><br>
> SSG/DPD/TCAR (Technical Computing, Analyzers and Runtimes)<br>
><br>
> Tel: <a href="tel:%2B44%20117%209071438" value="+441179071438">+44 117 9071438</a><br>
><br>
><br>
><br>
> From: Chandler Carruth [mailto:<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>]<br>
> Sent: Thursday, May 29, 2014 1:07 PM<br>
> To: Cownie, James H<br>
> Cc: Jack Howarth; <a href="mailto:openmp-dev@dcs-maillist2.engr.illinois.edu">openmp-dev@dcs-maillist2.engr.illinois.edu</a><br>
><br>
><br>
> Subject: Re: [Openmp-dev] initial clang-omp/openmp benchmarking<br>
><br>
><br>
><br>
><br>
><br>
> On Thu, May 29, 2014 at 4:45 AM, Cownie, James H <<a href="mailto:james.h.cownie@intel.com">james.h.cownie@intel.com</a>><br>
> wrote:<br>
><br>
> I don’t really understand what problem you are complaining about.<br>
><br>
> Your numbers show clang-omp as the fastest implementation in all directly<br>
> comparable cases. That doesn’t seem like something we want to change!<br>
><br>
><br>
> I think the complaint is this: on Darwin, the scaling to 4 "processes" is<br>
> worse than on Linux.<br>
><br>
><br>
><br>
> However, the reason is stated already: Linux provides a *very* fast futex<br>
> implementation. Darwin either doesn't provide it or iomp doesn't use it.<br>
><br>
><br>
><br>
> If Darwin provides a fast futex interface, then iomp should use it. That's a<br>
> useful request. I don't know enough about Darwin to help investigate whether<br>
> the OS has a futex interface exposed to userland.<br>
><br>
><br>
><br>
> If Darwin doesn't provide a futex interface, there is literally nothing we<br>
> can do about that. You aren't going to match the scalability of a<br>
> kernel-supported futex with something in userspace.<br>
><br>
><br>
><br>
> Anyways, I do agree that micro-optimizing mutex performance for something<br>
> like openmp seems somewhat less important....<br>
><br>
> ---------------------------------------------------------------------<br>
><br>
><br>
> Intel Corporation (UK) Limited<br>
> Registered No. 1134945 (England)<br>
> Registered Office: Pipers Way, Swindon SN3 1RJ<br>
> VAT No: 860 2173 47<br>
><br>
> This e-mail and any attachments may contain confidential material for<br>
> the sole use of the intended recipient(s). Any review or distribution<br>
> by others is strictly prohibited. If you are not the intended<br>
> recipient, please contact the sender and delete all copies.<br>
><br>
><br>
</div></div>> _______________________________________________<br>
> Openmp-dev mailing list<br>
> <a href="mailto:Openmp-dev@dcs-maillist2.engr.illinois.edu">Openmp-dev@dcs-maillist2.engr.illinois.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev</a><br>
><br>
<br>
_______________________________________________<br>
Openmp-dev mailing list<br>
<a href="mailto:Openmp-dev@dcs-maillist2.engr.illinois.edu">Openmp-dev@dcs-maillist2.engr.illinois.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev</a><br>
</blockquote></div><br></div>