On 03 January 2006 12:03, Chris Kuklewicz wrote: > STM* is usually slower than IO/MVar. STM has to do the transactional > record keeping and throws away work (i.e. CPU cycles and speed) when > it aborts. The Chameneos benchmark has 4 writers working *very* > quickly, so the contention is high. Taking the MVar acts like a > mutex to serialize access without throwing away work.
We found that once you add exception safety to your MVar code, i.e. using withMVar and modifyMVar rather than raw takeMVar/putMVar, then MVar code is comparable in speed to STM. For example, Chan and TChan perform about the same. Of course, for a benchmark, you can forget about the exception safety, as the Ch implementation does (plus it is tweaked in various other ways). > Also, I suspect the following may be true: > > If 4 threads block trying to take an MVar, and a 5th thread puts a > value in the MVar, then *exactly one* of the 4 blocked threads is > woken up and scheduled to run. Yes, that's true. We haven't documented this as a property of MVars, but we don't intend to change this behaviour, so I think we probably should document it. Furthermore, the thread to be woken up is always the first thread to block on the MVar. That is, there's a kind of fairness built into MVars which isn't present in STM and TMVars. > If 4 threads retry while in STM (e.g. takeTMVar), and a 5th thread > commits a change to that TMVar, then *all 4 threads* are woken up and > rescheduled. This is what the Apache httpd server folks called the > "thundering herd" problem when many processes are blocked waiting on > socket 80. > > If 4000 threads were getting woken up when only 1 was needed, then > performance would be poor. Certainly I found 4 writer thread and STM > to be much slower for this shootout problem than the Einar's custom > MVar channel. > > Could someone who knows the STM implementation comment on this? Hope this helps... Simon PJ and I talked about this briefly this morning, and agreed that it might be possible to provide more primitive MVar-like objects in STM to recover single-wakeup and some of the speed that MVars currently have. We haven't worked through the details though. >> This is the CVS code. newTChanIO is exported but undocumented in GHC >> 6.4.1. I'm not sure what purpose it serves. > > I get tired of writing "do tv <- atomically $ newTVar foo" > > I bet this is just shorthand: "do tv <- newTVarIO foo" > > Same for newTChanIO. It's not just shorthand: you can use newTVarIO and friends inside unsafePerformIO, which doesn't always work for the longhand atomically version. Cheers, Simon _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe