
From: Joel Reymont
To: "Branimir Maksimovic" CC: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Killer pickler combinators (was Time leak) Date: Wed, 21 Dec 2005 14:51:42 +0000 I'm not sure I buy this. Again, this helps:
{-# NOINLINE lock #-} lock :: MVar () lock = unsafePerformIO $ newMVar ()
trace s = withMVar lock $ const $ putStrLn s
and then in read_
cmd <- read h trace
trace is called _after_ all the timings in read so it should not affect the timings.
It does not affects timings directly , but indirectly. You have putStrLn which performs some work and that is point of serialization. Try no op instead of putStrLn and you should get timeouts again. i'm sure you'll get even better operation timings if you lock around whole timing operation instead. This will be valid only for single CPU only. In this way you actually get same throughoutput, with or without lock. It' just you have to measure cummulative reads/sec which will be same with/without lock for single CPU/worker thread. Again, only way to improve performance is to use more then one CPU/worker thread. Greetings, Bane.
You could basically say that the lock is at the end of read, after all the unpickling has been done. The other interesting thing is that replacing trace with
delay _ = threadDelay 1
does not solve the issue.
On Dec 21, 2005, at 2:33 PM, Branimir Maksimovic wrote:
In this code: do TOD time1 _ <- getClockTime (kind, ix1) <- unpickle puCmdType ptr ix TOD time2 _ <- getClockTime (cmd', _) <- unpickle (puCommand kind) ptr ix1 TOD time3 _ <- getClockTime you get time multiple times. So if you lock whole operation nothing else will be executed while in this code and therefore you don;t have timeouts. But, without lock more threads you have, more time have to wait for operation to finish and therefore timeouts.
_________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/