This is interesting, thanks.
I propose to add INLINE pragmas to withMVar and friends.
Having an interface for simple locks sounds like a good idea to me.
Would you like to send a patch?
This won't affect Handle I/O unfortunately, because we need block to
protect against asynchronous exceptions. I'm still not certain you
won't need that in the stream library, too: check any stateful code (eg.
buffering) and imagine what happens if an exception is raised at an
arbitrary point.
Cheers,
Simon
Bulat Ziganshin wrote:
> Main reason of slowness of existing Handle-based I/O in GHC is locking
> around each operation. it is especially bad for simple char-at-a-time
> I/O where 99% of time spent on locking and unlocking.
>
> To be exact, on my CPU, hPutChar for 100mb file requires 150 seconds,
> while hGetChar for the same file is "only" 100 seconds long. it seems
> that former use 3 locking operations and later 2 ones, because my own
> vGetChar/vPutChar implementations both requires 52 seconds, of those
> only about one second is real work and rest is just `withMVar`
> expenses.
>
> Until now, i thought that this 0.5 ms (about 1000 primitive CPU
> operations) on each withMVar is pure time required to perform
> takeMVar+putMVar operations. But yesterday i investigated this problem
> deeper and results was amazing!
>
> First, i just made local copy of `withMVar` and added INLINE to it:
>
> import Control.Exception as Exception
> {-# INLINE inlinedWithMVar #-}
> inlinedWithMVar :: MVar a -> (a -> IO b) -> IO b
> inlinedWithMVar m io =
> block $ do
> a <- takeMVar m
> b <- Exception.catch (unblock (io a))
> (\e -> do putMVar m a; throw e)
> putMVar m a
> return b
>
>
> Second, i've developed my own simplified version of this procedure.
> Here i should say that my library uses "MVar ()" field to hold lock
> and separate immutable data field with actual data locked:
>
> data WithLocking h = WithLocking h !(MVar ())
>
> This allowed me to omit block/unblock operation and develop the
> following faster analog of withMVar:
>
> lock (WithLocking h mvar) action = do
> Exception.catch (do takeMVar mvar
> result <- action h
> putMVar mvar ()
> return res
> )
> (\e -> do tryPutMVar mvar (); throw e)
>
> And as third variant i tried exception-unsafe variant of `withMVar`:
>
> unsafeWithMVar :: MVar a -> (a -> IO b) -> IO b
> unsafeWithMVar m io = do
> a <- takeMVar m
> b <- io a
> putMVar m a
> return b
>
>
> And now are results:
>
> withMVar 52 seconds
> inlinedWithMVar 38 seconds
> lock 20 seconds
> unsafeWithMVar 10 seconds
>
>
> So,
>
> 1) `withMVar` can be made significantly faster just by attaching
> INLINE pragma to it. until GHC includes this patch, you can just make
> local copy of this procedure (it's implementation is
> compiler-independent) and use INLINE pragma for this local copy
>
> 2) if MVar is used only to protect some immutable data from
> simultaneous access, it's use can be made significantly faster by
> using above-mentioned WithLocking type constructor together with
> 'lock' function. I hope that this mechanism will go into future
> Haskell implementations and in particular it will be used in my own
> Streams library and in new DiffArray implementation (that is a part
> of ArrayRef library)
>
> 3) For simple programs that don't catch exceptions anyway, this
> excessive protection is just meaningless. they can use
> 'unsafeWithMVar' to work as fast as possible. i mean in particular
> shootout-like benchmarks. it is also possible to develop fast & safe
> routines by using explicit unlocking (with 'tryPutMVar') in
> higher-level exception handlers
>
>
> and a more general conclusion. this case is a good demonstration of
> significant performance loss due to using of higher-order functions. i
> think that more aggressive inlining of high-order and polymorphic
> functions should significantly speed up GHC-compiled programs.
>
>
