On Sun, Jan 24, 2016 at 12:46 AM, Thomas Koster wrote:

Using Criterion, I have been running benchmarks to measure the relative performance of STM and MVars for some simple transactions that I expect will be typical in my application. I am using GHC 7.10.2 and libraries as at Stackage LTS 3.2.

I have found that STM is faster than MVars in all my benchmarks, without exception. This seems to go against accepted wisdom [1][2][3]. I have not included my source code here to save space, but if you suspect that I am using MVars incorrectly, just say so and I will post my source code separately.

I have two questions:

1. When are MVars faster than STM? If the answer is "never", then when are MVars "better" than STM? (Choose your own definition of "better".)

2. When given two capabilities (+RTS -N2), MVars are suddenly an order of magnitude slower than with just one capability. Why?

On 24 January 2016 at 17:55, Christopher Allen wrote:

Could you post the code please?

module Main (main) where import Control.Concurrent.Async import Control.Concurrent.MVar import Control.Concurrent.STM import Control.Monad import Criterion.Main main = defaultMain [ bgroup "thrash" [ bench "MVar" $ whnfIO (thrashTest mvarNew mvarInc mvarGet), bench "TVar" $ whnfIO (thrashTest tvarNew tvarInc tvarGet) ] ] thrashTest :: IO a -> (a -> IO ()) -> (a -> IO b) -> IO b thrashTest new inc get = do var <- new threads <- replicateM 4 (async (replicateM_ 100000 $ inc var)) forM_ threads wait get var mvarNew :: IO (MVar Int) mvarNew = newMVar 0 mvarInc :: MVar Int -> IO () mvarInc var = modifyMVar_ var $ \ i -> return $! succ i mvarGet :: MVar Int -> IO Int mvarGet = readMVar tvarNew :: IO (TVar Int) tvarNew = newTVarIO 0 tvarInc :: TVar Int -> IO () tvarInc var = atomically $ do i <- readTVar var writeTVar var $! succ i tvarGet :: TVar Int -> IO Int tvarGet = readTVarIO -- Thomas Koster

Ryan, On Sun, Jan 24, 2016 at 12:46 AM, Thomas Koster wrote:

Using Criterion, I have been running benchmarks to measure the relative performance of STM and MVars for some simple transactions that I expect will be typical in my application. I am using GHC 7.10.2 and libraries as at Stackage LTS 3.2.

I have found that STM is faster than MVars in all my benchmarks, without exception. This seems to go against accepted wisdom [1][2][3]. I have not included my source code here to save space, but if you suspect that I am using MVars incorrectly, just say so and I will post my source code separately.

I have two questions:

1. When are MVars faster than STM? If the answer is "never", then when are MVars "better" than STM? (Choose your own definition of "better".)

2. When given two capabilities (+RTS -N2), MVars are suddenly an order of magnitude slower than with just one capability. Why?

On 25 January 2016 at 01:04, Ryan Yates wrote:

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.

That is fair. From what I can tell, the time spent in the runtime dominates my user time, so I am basically benchmarking the GHC runtime, which I am not qualified to do :) I had only hoped to be able to decide on MVar vs STM before getting into the nitty gritty.

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.

Fairness may actually be very important to my application. Unlike my benchmark, the complexity of real transactions can vary enormously. Let me think about this. Thanks for your response. -- Thomas Koster

Yuras, On Sun, 2016-01-24 at 17:46 +1100, Thomas Koster wrote:

2. When given two capabilities (+RTS -N2), MVars are suddenly an order of magnitude slower than with just one capability. Why?

On 25 January 2016 at 02:09, Yuras Shumovich wrote:

One possible explanation is closure locking which is not performed when there is only one capability. In my quick measurements it gives 40% speedup: https://ghc.haskell.org/trac/ghc/ticket/693#comment:9

This makes sense. After all, why bother with locks and barriers when the process is single-threaded anyway? Thanks for your response. -- Thomas Koster

This has nothing to do with your questions, but are you sure that mvarInc is sufficiently strict? On 15:17, Sun, Jan 24, 2016 Christopher Allen wrote:

Well, there are cases where even with single-threading you want a memory barrier to prevent the CPU reordering instructions, but the shift to a single-threaded runtime should elide _some_ locks expressly designed to cope with multithreading.

On Sun, Jan 24, 2016 at 5:04 PM, Thomas Koster wrote:

...

Yuras,

On Sun, 2016-01-24 at 17:46 +1100, Thomas Koster wrote:

...

2. When given two capabilities (+RTS -N2), MVars are suddenly an order of magnitude slower than with just one capability. Why?

On 25 January 2016 at 02:09, Yuras Shumovich wrote:

...

One possible explanation is closure locking which is not performed when there is only one capability. In my quick measurements it gives 40% speedup: https://ghc.haskell.org/trac/ghc/ticket/693#comment:9

This makes sense. After all, why bother with locks and barriers when the process is single-threaded anyway?

Thanks for your response.

-- Thomas Koster _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe