<div dir="ltr"><div>Just to keep you all up to date...  I&#39;m adding the primops in question and validating the individual commits before putting them here:</div><div><div><br></div><div>    <a href="https://github.com/rrnewton/ghc/commits/atomicPrimOps">https://github.com/rrnewton/ghc/commits/atomicPrimOps</a><br>

</div><div><br></div><div>The basic idea for using these extensions is:<br></div><div><div><ul><li>the atomic-primops library will work in 7.6 or 7.7+.  It will use ifdefs to decide whether to use its own primops or GHC-builtin</li>

<li>future versions will simply get faster, as Carter replaces out-of-line primops that *also* use C calls, with inline primops / LLVM equivalents</li></ul></div></div><div>Shall I stick a patch on a ticket, or will someone volunteer to pull?  What&#39;s the protocol for requesting commit access anyway?  (By the way, can someone share the reason that pull-requests to the github ghc mirror are such a no-no?  They seem no worse than a patch in an email which the big <a href="https://github.com/ghc/ghc">warning sign</a> recommends.)</div>

<div><br></div><div>Best,</div><div>  -Ryan</div><div><br></div><div><div>P.S. FYI, I&#39;m periodically getting these: </div><div><br></div><div><span class="" style="white-space:pre">        </span>    0 caused framework failures</div>

<div><span class="" style="white-space:pre">        </span>    0 unexpected passes</div><div><span class="" style="white-space:pre">        </span>    1 unexpected failures</div><div><br></div><div>     Unexpected failures:</div><div>
<span class="" style="white-space:pre">        </span>perf/compiler  T1969 [stat not good enough] (normal)</div>
</div><div><br></div></div><div>Can that just be because of running on a loaded machine?  How narrow are these windows?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 1, 2013 at 12:32 PM, Ryan Newton <span dir="ltr">&lt;<a href="mailto:rrnewton@gmail.com" target="_blank">rrnewton@gmail.com</a>&gt;</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 class="im">On Sun, Jul 21, 2013 at 3:32 AM, Carter Schonwald <span dir="ltr">&lt;<a href="mailto:carter.schonwald@gmail.com" target="_blank">carter.schonwald@gmail.com</a>&gt;</span> wrote:<br>

</div><div class="gmail_extra">
<div class="gmail_quote"><div class="im">
<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>ok, could you add those comments (about additional operations to consider) to the ticket?</div>

</div>
</blockquote><div><br></div></div><div>Sure.  Just did that.</div><div class="im"><div> </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>relatedly: if we want these atomic ops to use the sequential analogues when we&#39;re not using the threaded run time system, does that mean </div>



<div>we need to have a symbol / constant variable exposed in the RTS we link in, so that the inline code branches on a linktime constant value / symbol (something like &quot;isThreadedRTS:: Bool&quot;, )  or some sort of analogue thereof?  </div>



</div></blockquote><div><br></div></div><div>I think it will take some care to mimic the semantics perfectly.  Why not just leave the real atomic ops even in non-threaded mode, at least at first?  Later we can optimize it if we find that people are using concurrent data structures heavily in non-threaded mode ;-). </div>

<div class="im">

<div> </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>one nice thing about doing such, is that if at some point link time optimization is added, the branch would go away! On the other hand, it could be argued that the cost of the call to the CAS primops in their current form isn&#39;t that much more expensive than such a branch. </div>


</div></blockquote><div><br></div></div><div>Indeed, I&#39;m much more concerned about performance in the threaded case and making sure they&#39;re correct.</div><div> </div></div></div></div>
</blockquote></div><br></div></div>