Re: Should folds in containers package remain INLINE

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 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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries