| 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-boun...@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 <b...@smart-cactus.org> wrote: | | > Joachim Breitner <nome...@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@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs