performance regressions

Tue Dec 16 13:49:05 UTC 2014

|  Using this combinator instead of writing the algorithm directly cost
|  me 30% allocation overhead!

That seems surprising.  I'd build a profiled compiler (GhcProfiled=YES) and see what it says.  

If it increases allocation by 30% overall, there must be a LOT of calls to this function.  Should there be so many?

S

|  -----Original Message-----
|  From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of
|  Richard Eisenberg
|  Sent: 16 December 2014 04:49
|  To: Ben Gamari
|  Cc: Joachim Breitner; ghc-devs at haskell.org
|  Subject: Re: performance regressions
|  
|  I've made progress, but still need some help.
|  
|  It turns out that a monadic combinator (that I wrote) is mostly
|  responsible:
|  
|  > zipWithAndUnzipM :: Monad m
|  >                  => (a -> b -> m (c, d)) -> [a] -> [b] -> m ([c],
|  [d])
|  > zipWithAndUnzipM f (x:xs) (y:ys)
|  >   = do { (c, d) <- f x y
|  >        ; (cs, ds) <- zipWithAndUnzipM f xs ys
|  >        ; return (c:cs, d:ds) }
|  > zipWithAndUnzipM _ _ _ = return ([], [])
|  >
|  
|  Using this combinator instead of writing the algorithm directly cost
|  me 30% allocation overhead!
|  
|  Can anyone tell me: why? Have I made some horrible mistake in the
|  implementation?
|  And, relatedly: how can I fix this? I want to learn from this
|  experience how to avoid this problem next time...
|  
|  Unfortunately, my commit causes 50% overhead, not 30%, so I'm not out
|  of the woods yet. Hopefully, another 20% of good news tomorrow.
|  
|  Thanks!
|  Richard
|  
|  On Dec 15, 2014, at 11:33 AM, Ben Gamari <ben at smart-cactus.org> wrote:
|  
|  > Joachim Breitner <nomeata at debian.org> writes:
|  >
|  >> Hi,
|  >>
|  >> Am Montag, den 15.12.2014, 10:58 -0500 schrieb Ben Gamari:
|  >>>>> - Travis has not picked up on these errors.
|  >>>>
|  >>>> unfortunately, travis is slighly less useful since a few weeks
|  due
|  >>>> to
|  >>>> T5681 failing (possibly due to the use of LLVM-3.4), but I'm
|  still
|  >>>> waiting for an reply on that issue.
|  >>>>
|  >>> You aren't looking for a response from me on this, are you? I just
|  >>> checked and I don't seem to have any outstanding messages from you
|  >>> but it's entirely possible I overlooked something.
|  >>
|  >> this is independent of our arm issues, and I think a tad older; I
|  did
|  >> not direct it to anyone specific.
|  >>
|  >> But I guess you are likely a person that can tell what's wrong
|  here:
|  >>
|  >> Am Sonntag, den 30.11.2014, 20:01 +0100 schrieb Joachim Breitner:
|  >>> Compile failed (status 256) errors were:
|  >>> /tmp/ghc16123_0/ghc16123_5.s: Assembler messages:
|  >>>
|  >>> /tmp/ghc16123_0/ghc16123_5.s:26:0:
|  >>>     Error: can't resolve `.rodata' {.rodata section} -
|  >>> `Main_zdwwork_info$def' {.text section}
|  >>>
|  >>> /tmp/ghc16123_0/ghc16123_5.s:46:0:
|  >>>     Error: can't resolve `.rodata' {.rodata section} -
|  >>> `Main_work_info$def' {.text section}
|  >>>
|  >>> /tmp/ghc16123_0/ghc16123_5.s:66:0:
|  >>>     Error: can't resolve `.rodata' {.rodata section} -
|  >>> `Main_main1_info$def' {.text section}
|  >>>
|  >>> /tmp/ghc16123_0/ghc16123_5.s:86:0:
|  >>>     Error: can't resolve `.rodata' {.rodata section} -
|  >>> `Main_main_info$def' {.text section}
|  >>>
|  >>> /tmp/ghc16123_0/ghc16123_5.s:106:0:
|  >>>     Error: can't resolve `.rodata' {.rodata section} -
|  >>> `Main_main2_info$def' {.text section}
|  >>>
|  >>> /tmp/ghc16123_0/ghc16123_5.s:126:0:
|  >>>     Error: can't resolve `.rodata' {.rodata section} -
|  >>> `ZCMain_main_info$def' {.text section}
|  >>>
|  >>> *** unexpected failure for T5681(optllvm)
|  >>>
|  >>> https://s3.amazonaws.com/archive.travis-
|  ci.org/jobs/42557559/log.txt
|  >>>
|  >>> Any ideas?
|  >>
|  >> Is it possible that this is due the llvm version used? Do we
|  support
|  >> 3.4 in GHC HEAD?
|  >>
|  >>   Using LLVM tools
|  >>      llc   : /usr/local/clang-3.4/bin/llc
|  >>      opt   : /usr/local/clang-3.4/bin/opt
|  >>
|  >> (http://smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-
|  backend.
|  >> html does not talk about GHC HEAD explicitly. Should I look at the
|  >> 7.10 row? Does that mean that 3.4 is not supported? Shouldn't the
|  >> build system, or at least the compiler, fail harder and more
|  >> helpfully in this case?)
|  >>
|  > LLVM 3.4 appears to have an unfortunate behavior whereby it will
|  lose
|  > track of which section symbols with Internal linkage belong.  I
|  > haven't had a chance to delve into this too deeply, however given
|  that
|  > both 3.3 and
|  > 3.5 behave as expected I'm pretty sure this a bug. There are a few
|  > options here,
|  >
|  >  a. Mark the `$def` symbols as ExternallyVisible, working around the
|  > issue at the expense of exposing internal symbols to the outside
|  > world.
|  >
|  >  b. Mark LLVM 3.4 as unsupported
|  >
|  > At the moment I'm leaning towards (b) since I haven't had a chance
|  to
|  > think through the implications of (a); if nothing else I suspect
|  this
|  > wouldn't help the DLL symbol table size issues on Windows. Giving up
|  > on LLVM 3.4 might be unfortunate for a good number of users,
|  however.
|  >
|  > Ultimately this underlines the need to package LLVM with GHC.
|  >
|  > Cheers,
|  >
|  > - Ben
|  >
|  >
|  > _______________________________________________
|  > ghc-devs mailing list
|  > ghc-devs at haskell.org
|  > http://www.haskell.org/mailman/listinfo/ghc-devs
|  
|  _______________________________________________
|  ghc-devs mailing list
|  ghc-devs at haskell.org
|  http://www.haskell.org/mailman/listinfo/ghc-devs