Should folds in containers package remain INLINE
marlowsd at gmail.com
Wed May 2 13:16:35 CEST 2012
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
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?
>>> Libraries mailing list
>>> Libraries at haskell.org
>> Libraries mailing list
>> Libraries at haskell.org
> Libraries mailing list
> Libraries at haskell.org
More information about the Libraries