Should folds in containers package remain INLINE

[Simon Marlow]

I would like the folds to be INLINABLE.  Rationale:

  - The 0.8% figure is really plucked out of thin air, it depends
    entirely on how many times we call fold.

  - Getting a complete copy of fold each time you call it is overkill.

  - INLINABLE puts the user in control of the performance/size
    tradeoff; with INLINE the user has no control, they always get
    a copy (well, they could write a NOINLINE wrapper, but that's
    horrible).

just MHO...

Cheers,
	Simon


On 26/04/2012 18:35, Johan Tibell wrote:
> I agree with Ryan, I think we should keep the INLINEs on folds. It's a
> nice property of the current implementation that folds will be as fast
> as handrolled recursive traversals over the data type.
>
> On Thu, Apr 26, 2012 at 7:22 AM, Ryan Newton<rrnewton at gmail.com>  wrote:
>> It doesn't seem like enough of a code size reduction to justify the change in this case.
>>
>> Is there any opportunity to attack this problem later in the compiler?  Perhaps a CSE for similar blocks of code?  I've noticed enormous reductions in size using UPX, so I know these binaries themselves are quite compressible.
>>
>> Sent from my cell phone
>>
>> On Apr 26, 2012, at 7:10 AM, Milan Straka<fox at ucw.cz>  wrote:
>>
>>> Hi all,
>>>
>>> this came up when discussing increasing size of GHC binary.
>>>
>>> Currently all folds in containers package are marked as INLINE. This has
>>> following effects:
>>>
>>> 1) the code using folds can be (much) more efficient -- for example, when
>>>    calling statically known function. If the unfolding of that function
>>>    is available, GHC can spot strictness and unbox values -- so
>>>    `foldl (+) (0::Int)` evaluated the sum strictly and without
>>>    allocating space for intermediate Ints.
>>>
>>> 2) the resulting binary size increases. If the folds in containers
>>>    package are not INLINEd, the stripped GHC binary shrinks by 303kB,
>>>    which is 0.8% of its size.
>>>
>>> Therefore we have speed vs. code size trade-off. FYI, Prelude.foldr is
>>> always inlined, Prelude.foldl is inlined only when GHC thinks it is
>>> worth it.
>>>
>>>
>>> Simon Marlow suggested that folds could be marked INLINABLE. Then they
>>> would probably not be inlined automatically, but one could say
>>>   inline foldr
>>> to inline the fold on the call sites she chooses.
>>>
>>>
>>> Personally I am a bit in favor of keeping the folds INLINE. That allows
>>> the users of containers to get best performance without any change to
>>> the code (i.e., adding explicit `inline`). The price to pay is code size
>>> increase, which I consider minor (0.8% for GHC binary).
>>>
>>> Any other thoughts?
>>>
>>> Cheers,
>>> Milan
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://www.haskell.org/mailman/listinfo/libraries
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries