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