Should folds in containers package remain INLINE
johan.tibell at gmail.com
Thu Apr 26 19:35:48 CEST 2012
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?
>> Libraries mailing list
>> Libraries at haskell.org
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries