Hi,<div><br></div><div>I was interested in Distruptor few months ago and started to write a Haskell implementation. Soon I discovered the lack of native CAS operations and abandoned project for a while. I don&#39;t really have time to develop it further right now, but the code is available: 
<a href="https://github.com/Tener/disruptor-hs" target="_blank">https://github.com/Tener/disruptor-hs</a> </div><div><br></div><div>The code as it is now is mostly benchmarking code. I think it is worth trying out.</div>


<div><br></div><div>You mention benchmarking TChans: one particular problem with TChans and Chans is that they are unbounded. If the producers outpace consumers it soon ends with memory exhaustion.</div><div><br></div><div>


In the process of writing above code I discovered particularly simple data structure that performs suprisingly well (full implementation: <a href="https://github.com/Tener/disruptor-hs/blob/master/Test/ManyQueue.hs" target="_blank">https://github.com/Tener/disruptor-hs/blob/master/Test/ManyQueue.hs</a>) :</div>



<div><br></div><div><font face="&#39;courier new&#39;, monospace">type Queue a = [MVar a]</font></div><div><font face="&#39;courier new&#39;, monospace">mkQueue size = cycle `fmap` (replicateM size newEmptyMVar)</font></div>



<div><br></div><div><br>The throutput is very high, it is bounded and scales well with the number of producer/consumers threads. In the presence of multiple consumers/producers it&#39;s not a FIFO queue though, but rather a kind of buffer with funny ordering.</div>

<div>

<br></div><div>Best regards,</div><div>Krzysztof Skrzętnicki<br><br><div class="gmail_quote">On Fri, Mar 30, 2012 at 00:03, John Lato <span dir="ltr">&lt;<a href="mailto:jwlato@gmail.com" target="_blank">jwlato@gmail.com</a>&gt;</span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Slightly related: I think it would be interesting to compare a<br>
Disruptor-based concurrency communications mechanism and compare it to<br>
e.g. TChans<br>
<br>
1.  Disruptor - <a href="http://code.google.com/p/disruptor/" target="_blank">http://code.google.com/p/disruptor/</a><br>
<br>
&gt; From: Ryan Newton &lt;<a href="mailto:rrnewton@gmail.com" target="_blank">rrnewton@gmail.com</a>&gt;<br>
&gt;<br>
&gt;&gt; I think so. Atomically reading and writing a single memory location<br>
&gt;&gt;&gt; (which CAS does) is just a very simple transaction. But using a CAS<br>
&gt;&gt;&gt; instruction should be more efficient, since STM has to maintain a<br>
&gt;&gt;&gt; transaction log and commit transactions, which creates some overhead.<br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Ah, I see. In that case, it may be worthwhile to implement the CAS<br>
&gt;&gt; instruction in terms of STM as well and measure the performance difference<br>
&gt;&gt; this makes for the final data structure. After all, STM is a lot more<br>
&gt;&gt; compositional than CAS, so I&#39;d like to know whether the loss of<br>
&gt;&gt; expressiveness is worth the gain in performance.<br>
&gt;<br>
&gt;<br>
&gt; There&#39;s one annoying hitch with doing apples-to-apples comparisons here.<br>
&gt;<br>
&gt; The problem is that CAS falls short of being a hardware-accelerated version<br>
&gt; of a simple transaction (read TVar, (==) against expected value,<br>
&gt; conditionally update TVar), because CAS is based on pointer equality rather<br>
&gt; than true equality.  (eq? rather than equal? for any Schemers out there.)<br>
&gt;<br>
&gt; For this reason our &quot;Fake&quot; version of CAS -- for older GHCs and for<br>
&gt; performance comparison -- has to use reallyUnsafePointerEquality#:<br>
&gt;<br>
&gt;<br>
&gt; <a href="http://hackage.haskell.org/packages/archive/IORefCAS/0.2/doc/html/Data-CAS-Internal-Fake.html" target="_blank">http://hackage.haskell.org/packages/archive/IORefCAS/0.2/doc/html/Data-CAS-Internal-Fake.html</a><br>




&gt;<br>
&gt; But we do provide a &quot;CASable&quot; type class in that package which is precisely<br>
&gt; for comparing the performance of:<br>
&gt;<br>
&gt;   - Hardware CAS<br>
&gt;   - Fake CAS -- atomicModifyIORef + ptrEquality<br>
&gt;   - Foreign CAS -- gcc intrinsic + function call<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org" target="_blank">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br></div>