| 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@haskell.org] On Behalf Of
| Richard Eisenberg
| Sent: 16 December 2014 04:49
| To: Ben Gamari
| Cc: Joachim Breitner; ghc-devs@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 wrote:
|
| > Joachim Breitner 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@haskell.org
| > http://www.haskell.org/mailman/listinfo/ghc-devs
|
| _______________________________________________
| ghc-devs mailing list
| ghc-devs@haskell.org
| http://www.haskell.org/mailman/listinfo/ghc-devs
