<div dir="ltr">Ryan, is your benchmark using CAS on pointers, or immediate words? trying to get atomic primops to build on my 7.8 build on my mac</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 1, 2014 at 2:44 AM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><a href="https://ghc.haskell.org/trac/ghc/ticket/8724#ticket" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/8724#ticket</a> is the ticket<br>
<div><br></div><div>when i'm more awake i'll experiment some more</div>
</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 1, 2014 at 2:33 AM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">i have a ticket for tracking this, though i'm thinking my initial attempt at a patch generates the same object code as it did before.<div>
<br></div><div>@ryan, what CPU variant are you testing this on? is this on a NUMA machine or something?</div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 1, 2014 at 1:58 AM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">woops, i mean cmpxchgq</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sat, Feb 1, 2014 at 1:36 AM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">ok, i can confirm that on my 64bit mac, both clang and gcc use cmpxchgl rather than cmpxchg<div>i'll whip up a strawman patch on head that can be cherrypicked / tested out by ryan et al</div>
</div><div><div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 1, 2014 at 1:12 AM, Carter Schonwald <span dir="ltr"><<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey Ryan,<div>looking at this closely<br><div>Why isn't CAS using CMPXCHG8B on 64bit architectures? Could that be the culprit? <br>
</div></div><div><br></div><div>Could the issue be that we've not had a good stress test that would create values that are equal on the 32bit range, but differ on the 64bit range, and you're hitting that?</div>
<div><br></div><div>Could you try seeing if doing that change fixes things up?</div><div>(I may be completely wrong, but just throwing this out as a naive "obvious" guess)</div></div><div class="gmail_extra">
<br><br><div class="gmail_quote"><div><div>On Sat, Feb 1, 2014 at 12:58 AM, Ryan Newton <span dir="ltr"><<a href="mailto:rrnewton@gmail.com" target="_blank">rrnewton@gmail.com</a>></span> wrote:<br></div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<div dir="ltr">Then again... I'm having trouble seeing how the spec on page 3-149 of the Intel manual would allow the behavior I'm seeing:<div><br></div><div><a href="http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf" target="_blank">http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf</a><br>
</div><div><br></div><div>Nevertheless, this is exactly the behavior we're seeing with the current Haskell primops. Two threads simultaneously performing the same CAS(p,a,b) can both think that they succeeded.</div>
<div>
<br></div><div><br></div><div><br></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 1, 2014 at 12:33 AM, Ryan Newton <span dir="ltr"><<a href="mailto:rrnewton@gmail.com" target="_blank">rrnewton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I commented on the commit here:</div><div><br></div><div> <a href="https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b" target="_blank">https://github.com/ghc/ghc/commit/521b792553bacbdb0eec138b150ab0626ea6f36b</a><br>
</div><div><br></div><div>The problem is that our "cas" routine in SMP.h is similar to the C compiler intrinsic __sync_val_compare_and_swap, in that it returns the old value. But it seems we cannot use a comparison against that old value to determine whether or not the CAS succeeded. (I believe the CAS may fail due to contention, but the old value may happen to look like our old value.)</div>
<div><br></div><div>Unfortunately, this didn't occur to me until it started causing bugs [1] [2]. Fixing casMutVar# fixes these bugs. However, the way I'm currently fixing CAS in the "atomic-primops" package is by using __sync_bool_compare_and_swap:</div>
<div><br></div> <a href="https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200" target="_blank">https://github.com/rrnewton/haskell-lockfree/commit/f9716ddd94d5eff7420256de22cbf38c02322d7a#diff-be3304b3ecdd8e1f9ed316cd844d711aR200</a><br>
<div><br></div><div>What is the best fix for GHC itself? Would it be ok for GHC to include a C compiler intrinsic like __sync_val_compare_and_swap? Otherwise we need another big ifdbef'd function like "cas" in SMP.h that has the architecture-specific inline asm across all architectures. I can write the x86 one, but I'm not eager to try the others.</div>
<div><br></div><div>Best,</div><div> -Ryan</div><div><br></div><div>[1] <a href="https://github.com/iu-parfunc/lvars/issues/70" target="_blank">https://github.com/iu-parfunc/lvars/issues/70</a></div><div>[2] <a href="https://github.com/rrnewton/haskell-lockfree/issues/15" target="_blank">https://github.com/rrnewton/haskell-lockfree/issues/15</a></div>
<div><br></div></div>
</blockquote></div><br></div>
</div></div><br></div></div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>