Should folds in containers package remain INLINE
rrnewton at gmail.com
Thu Apr 26 16:22:17 CEST 2012
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
More information about the Libraries