performance regressions

[Richard Eisenberg]

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