Perf regression: ghc --make: add nicer names to RTS threads (threaded IO manager, make workers) (f686682)

[Joachim Breitner]

Hi Sergei,

Am Mittwoch, den 06.08.2014, 22:15 +0300 schrieb Sergei Trofimovich:
> On Wed, 06 Aug 2014 09:30:45 +0200 Joachim Breitner <mail at joachim-breitner.de> wrote:
> > the attached commit seems to have regressed the scs nofib benchmark by
> > ~3%:
> > http://ghcspeed-nomeata.rhcloud.com/timeline/?ben=nofib/time/scs&env=1#/?exe=2&base=2+68&ben=nofib/time/scs&env=1&revs=50&equid=on
> 
> That's a test of compiled binary performance, not the compiler, right?

Correct.

> > The graph unfortunately is in the wrong order, as the tool gets confused
> > by timezones and by commits with identical CommitDate, e.g. due to
> > rebasing. This needs to be fixed, I manually verified that the commit
> > below is the first that shows the above-noise-level-increase of runtime.
> > 
> > (Other benchmarks seem to be unaffected.)
> > 
> > Is this regression expected and intended or unexpected? Is it fixable?
> > Or is is this simply inexplicable?
> 
> The graph looks mysterious (18 ms bump). Bencmark does not use haskell
> threads at all.

Yes, I was surprised by that as well.

> I'll try to reproduce degradation locally and will investigate.

Thanks!

> The only runtime part affected by the patch only renames threads
> (the renamer gets called once for each created thread):
> 
> > > diff --git a/libraries/base/GHC/Event/Thread.hs b/libraries/base/GHC/Event/Thread.hs
> > > index 6e991bf..dcfa32a 100644
> > > --- a/libraries/base/GHC/Event/Thread.hs
> > > +++ b/libraries/base/GHC/Event/Thread.hs
> > > @@ -39,6 +39,7 @@ import GHC.Event.Manager (Event, EventManager, evtRead, evtWrite, loop,
> > >  import qualified GHC.Event.Manager as M
> > >  import qualified GHC.Event.TimerManager as TM
> > >  import GHC.Num ((-), (+))
> > > +import GHC.Show (showSignedInt)
> > >  import System.IO.Unsafe (unsafePerformIO)
> > >  import System.Posix.Types (Fd)
> > >  
> > > @@ -244,11 +245,14 @@ startIOManagerThreads =
> > >      forM_ [0..high] (startIOManagerThread eventManagerArray)
> > >      writeIORef numEnabledEventManagers (high+1)
> > >  
> > > +show_int :: Int -> String
> > > +show_int i = showSignedInt 0 i ""
> > > +
> > >  restartPollLoop :: EventManager -> Int -> IO ThreadId
> > >  restartPollLoop mgr i = do
> > >    M.release mgr
> > >    !t <- forkOn i $ loop mgr
> > > -  labelThread t "IOManager"
> > > +  labelThread t ("IOManager on cap " ++ show_int i)
> > >    return t
> > >  
> > >  startIOManagerThread :: IOArray Int (Maybe (ThreadId, EventManager))
> > > @@ -258,7 +262,7 @@ startIOManagerThread eventManagerArray i = do
> > >    let create = do
> > >          !mgr <- new True
> > >          !t <- forkOn i $ loop mgr
> > > -        labelThread t "IOManager"
> > > +        labelThread t ("IOManager on cap " ++ show_int i)
> > >          writeIOArray eventManagerArray i (Just (t,mgr))
> > >    old <- readIOArray eventManagerArray i
> > >    case old of

It does replace a reference to the a string ("IOManager") by something
involving allocation and computation. I guess that could have a
measurable effect.

What happens to programs relying on very cheap threads? Do we have
benchmarks for this class of programs at all?

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0xF0FBF51F
  Debian Developer: nomeata at debian.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140806/d5e0be37/attachment.sig>