<div dir="ltr"><div>Hi Thomas,</div><div><br></div>I'm sorry I don't have time right now for a proper response (buried under paper deadlines).  There are certainly times when one will be faster then the other and the reasons are quite complicated.  To complicate matters further it is very difficult to get benchmarks that don't lie about performance in this space.  There are also alternative implementations that change the balance drastically.  The only broad advice I can give is to benchmark the target application with both implementations to see how all the implications fall out.  A broad description of the differences in implementation would be that MVars have a fairness guarantee (that does not come for free) for waking waiting threads.  STM does not have this fairness which can lead to problems for programs that have quick transactions that always win over occasional long transactions (there are ways to avoid with a different implementation or with the cost of shifted to the programmer).  My guess is in your particular benchmark the unfairness of STM works to your advantage and all the work is happening sequentially while the MVar version's fairness incurs frequent cache misses.<div><br></div><div><br></div><div>Ryan</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 24, 2016 at 2:13 AM, Thomas Koster <span dir="ltr"><<a href="mailto:tkoster@gmail.com" target="_blank">tkoster@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, Jan 24, 2016 at 12:46 AM, Thomas Koster <<a href="mailto:tkoster@gmail.com">tkoster@gmail.com</a>> wrote:<br>
</span><span class="">> Using Criterion, I have been running benchmarks to measure the<br>
> relative performance of STM and MVars for some simple transactions<br>
> that I expect will be typical in my application. I am using GHC 7.10.2<br>
> and libraries as at Stackage LTS 3.2.<br>
><br>
> I have found that STM is faster than MVars in all my benchmarks,<br>
> without exception. This seems to go against accepted wisdom [1][2][3].<br>
> I have not included my source code here to save space, but if you<br>
> suspect that I am using MVars incorrectly, just say so and I will post<br>
> my source code separately.<br>
><br>
> I have two questions:<br>
><br>
> 1. When are MVars faster than STM? If the answer is "never", then when<br>
> are MVars "better" than STM? (Choose your own definition of "better".)<br>
><br>
> 2. When given two capabilities (+RTS -N2), MVars are suddenly an order<br>
> of magnitude slower than with just one capability. Why?<br>
<br>
<br>
</span><span class="">On 24 January 2016 at 17:55, Christopher Allen <<a href="mailto:cma@bitemyapp.com">cma@bitemyapp.com</a>> wrote:<br>
> Could you post the code please?<br>
<br>
<br>
</span>module Main (main) where<br>
<br>
import Control.Concurrent.Async<br>
import Control.Concurrent.MVar<br>
import Control.Concurrent.STM<br>
import Control.Monad<br>
import Criterion.Main<br>
<br>
main =<br>
  defaultMain<br>
    [<br>
      bgroup "thrash"<br>
        [<br>
          bench "MVar" $ whnfIO (thrashTest mvarNew mvarInc mvarGet),<br>
          bench "TVar" $ whnfIO (thrashTest tvarNew tvarInc tvarGet)<br>
        ]<br>
    ]<br>
<br>
thrashTest :: IO a<br>
           -> (a -> IO ())<br>
           -> (a -> IO b)<br>
           -> IO b<br>
thrashTest new inc get = do<br>
  var <- new<br>
  threads <- replicateM 4 (async (replicateM_ 100000 $ inc var))<br>
  forM_ threads wait<br>
  get var<br>
<br>
mvarNew :: IO (MVar Int)<br>
mvarNew = newMVar 0<br>
<br>
mvarInc :: MVar Int -> IO ()<br>
mvarInc var =<br>
  modifyMVar_ var $ \ i -><br>
    return $! succ i<br>
<br>
mvarGet :: MVar Int -> IO Int<br>
mvarGet = readMVar<br>
<br>
tvarNew :: IO (TVar Int)<br>
tvarNew = newTVarIO 0<br>
<br>
tvarInc :: TVar Int -> IO ()<br>
tvarInc var =<br>
  atomically $ do<br>
    i <- readTVar var<br>
    writeTVar var $! succ i<br>
<br>
tvarGet :: TVar Int -> IO Int<br>
tvarGet = readTVarIO<br>
<br>
--<br>
<div class="HOEnZb"><div class="h5">Thomas Koster<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br></div>