Re: [Haskell-cafe] Too much inlining on text package
On Apr 8, 2012 8:47 AM, Bryan Oapos;Sullivan b...@serpentine.com wrote: On Sun, Mar 18, 2012 at 12:02 AM, Michael Snoyman mich...@snoyman.com wrote: OK, issue created: https://github.com/bos/text/issues/19 I fixed the too-much-inlining bug tonight. As a bonus, Text literals are now decoded straight from GHC's packed encoding, without an intermediate step through String. Generated code now looks like this at -O and above: $ ghc -O -ddump-simpl -c CS.hs CS.foo :: Data.Text.Internal.Text [GblId, ...] CS.foo = Data.Text.unpackCString# x\NULy This looks great Bryan, thank you! Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Too much inlining on text package
On Sun, Apr 8, 2012 at 2:47 AM, Bryan O'Sullivan b...@serpentine.com wrote: I fixed the too-much-inlining bug tonight. As a bonus, Text literals are now decoded straight from GHC's packed encoding, without an intermediate step through String. Generated code now looks like this at -O and above: $ ghc -O -ddump-simpl -c CS.hs CS.foo :: Data.Text.Internal.Text [GblId, ...] CS.foo = Data.Text.unpackCString# x\NULy Very nice! =) Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Too much inlining on text package
On Sun, Mar 18, 2012 at 12:02 AM, Michael Snoyman mich...@snoyman.comwrote: OK, issue created: https://github.com/bos/text/issues/19 I fixed the too-much-inlining bughttps://github.com/bos/text/commit/2b2cb084c4689c06f1a7851ff8eb1e412eb02c1btonight. As a bonus, Text literals are now decoded straight from GHC's packed encoding, without an intermediate step through String. Generated code now looks like this at -O and above: $ ghc -O -ddump-simpl -c CS.hs CS.foo :: Data.Text.Internal.Text [GblId, ...] CS.foo = Data.Text.unpackCString# x\NULy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Too much inlining on text package
On Sat, Mar 17, 2012 at 1:28 AM, Johan Tibell johan.tib...@gmail.com wrote: On Fri, Mar 16, 2012 at 3:48 PM, Aleksey Khudyakov alexey.sklad...@gmail.com wrote: On 17.03.2012 02:24, Johan Tibell wrote: I suggest you file a bug. :) I'm way too lazy for that. Also I don't want to steal joy of reporting a bug from people who actually suffer from it I meant you as in the collective you who care about this, not you specifically. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe OK, issue created: https://github.com/bos/text/issues/19 If anyone has concrete ideas on how to improve the situation, could you comment on Github and/or send it as a pull request? Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Too much inlining on text package
Hello!
tl;dr: text package's pack function is creating huge chunks of code everywhere.
Michael Snoyman and I have been trying to nail the performance
problems of persistent's Template Haskell code -- GHC was taking a lot
of memory and CPU time to compile these. What we found out is that
the code size was getting increased 20-fold by the simplifier on phase
0 on GHC 7.0 (c.f.
http://groups.google.com/group/yesodweb/msg/9f625fcf85575263). So,
what was increasing in size?
Consider this extremely simple module (attached as Bug.hs):
module Bug (text) where
import qualified Data.Text as T
text :: T.Text
text = T.pack text
Until simplifier phase 0, the code size floats but tops at 12. Here's the core:
Bug.text :: Data.Text.Internal.Text
[LclIdX,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=0, Value=False,
ConLike=False, Cheap=False, Expandable=False,
Guidance=IF_ARGS [] 11 0}]
Bug.text =
Data.Text.Fusion.unstream
(Data.Text.Fusion.Common.streamList
@ GHC.Types.Char
(GHC.Base.map
@ GHC.Types.Char
@ GHC.Types.Char
Data.Text.Internal.safe
(GHC.Base.unpackCString# text)))
Which is straightforward. However, on simplifier phase 0 the code
size jumps to 391 (!!), a 32-fold increase. I've attached the core
(after.hs) since it's too large to copy here on the body. So it seems
that the (unstream . streamList) pair above is getting inlined to a
HUGE chunk of code (at least Data.Text.Array.new is getting inlined).
Worse yet, this happens for every single pack that you use, even those
packs hidden by OverloadedStrings!
Does anyone have any ideas why GHC is inlining so much code
everywhere? While everything I said here was tested on GHC 7.0, we
have evidence that GHC 7.4 suffers from the same problem. We don't
know about GHC 6.12, though. This seems to be a problem for everyone
who uses text, which we hope is everyone using Haskell ;-).
Cheers,
--
Felipe.
Simplifier SimplMode {Phase = 0 [main],
inline,
rules,
eta-expand,
case-of-case} max-iterations=4 iteration=2
Bug.text :: Data.Text.Internal.Text
[LclIdX,
Unf=Unf{Src=vanilla, TopLvl=True, Arity=0, Value=False,
ConLike=False, Cheap=False, Expandable=False, Guidance=NEVER}]
Bug.text =
case GHC.Base.map
@ GHC.Types.Char
@ GHC.Types.Char
Data.Text.Internal.safe
(GHC.Base.unpackCString# text)
of tpl_arP { __DEFAULT -
letrec {
a_stU
:: forall s1_ao6.
Data.Text.Array.MArray s1_ao6
- GHC.Types.Int
- [GHC.Types.Char]
- GHC.Types.Int
- GHC.Prim.State# s1_ao6
- (# GHC.Prim.State# s1_ao6,
(Data.Text.Array.MArray s1_ao6, GHC.Types.Int) #)
[LclId,
Arity=5,
Unf=Unf{Src=vanilla, TopLvl=False, Arity=5, Value=True,
ConLike=True, Cheap=True, Expandable=True, Guidance=NEVER}]
a_stU =
\ (@ s1_ao6)
(arr_ao7 :: Data.Text.Array.MArray s1_ao6)
(top_ao8 :: GHC.Types.Int)
(eta_B3 :: [GHC.Types.Char])
(eta_B2 :: GHC.Types.Int)
(eta_B1 :: GHC.Prim.State# s1_ao6) -
letrec {
a_stS
:: [GHC.Types.Char]
- GHC.Types.Int
- GHC.Prim.State# s1_ao6
- (# GHC.Prim.State# s1_ao6,
(Data.Text.Array.MArray s1_ao6, GHC.Types.Int) #)
[LclId,
Arity=3,
Unf=Unf{Src=vanilla, TopLvl=False, Arity=3, Value=True,
ConLike=True, Cheap=True, Expandable=True, Guidance=NEVER}]
a_stS =
\ (s_aoa :: [GHC.Types.Char])
(i_aob :: GHC.Types.Int)
(eta_Xf :: GHC.Prim.State# s1_ao6) -
case s_aoa of s1_aoI { __DEFAULT -
case i_aob of i1_aoJ { GHC.Types.I# ipv_aoL -
case s1_aoI of _ {
[] - (# eta_Xf, (arr_ao7, i1_aoJ) #);
: x_arU xs_arV -
case x_arU of tpl1_arX { GHC.Types.C# ipv_stw -
case xs_arV of tpl2_arY { __DEFAULT -
let {
a_ape
:: GHC.Prim.State# GHC.Prim.RealWorld
- GHC.Prim.State# s1_ao6
- (# GHC.Prim.State# s1_ao6,
(Data.Text.Array.MArray s1_ao6, GHC.Types.Int) #)
[LclId,
Arity=2,
Unf=Unf{Src=vanilla, TopLvl=False, Arity=2, Value=True,
ConLike=True, Cheap=True, Expandable=True,
Guidance=IF_ARGS [0 0] 38 12}]
a_ape =
\ _ (s2_apg :: GHC.Prim.State# s1_ao6) -
let {
x1_aph :: GHC.Prim.Int#
[LclId,
Re: [Haskell-cafe] Too much inlining on text package
On 16.03.2012 17:41, Felipe Almeida Lessa wrote: Does anyone have any ideas why GHC is inlining so much code everywhere? While everything I said here was tested on GHC 7.0, we have evidence that GHC 7.4 suffers from the same problem. We don't know about GHC 6.12, though. This seems to be a problem for everyone who uses text, which we hope is everyone using Haskell ;-). Disclaimer. I'm no expert in text internals. Because it's told to do so. This is an unfortunate feature of stream fusion. It does eliminate intermediate data structures but it requires that everything is inlined. It looks like most of the code comes from unstream[1] function. I'm not sure that unstream has to be inlined. I suppose yes so stepper function is inlined. [1] https://github.com/bos/text/blob/master/Data/Text/Fusion.hs#L95 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Too much inlining on text package
On 3/16/12 12:22 PM, Aleksey Khudyakov wrote: Disclaimer. I'm no expert in text internals. Because it's told to do so. This is an unfortunate feature of stream fusion. It does eliminate intermediate data structures but it requires that everything is inlined. There are ways of mitigating that, however. In particular, the standard style is to have things inline aggressively before stage 0 or 1, and then in the last stage to inline things back to an indirect call to the library. This is used ubiquitously in GHC's list fusion, and is essential for stream-fusion since the intermediate stream form is a pessimation when it can't partake in fusion. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Too much inlining on text package
On 17.03.2012 01:51, wren ng thornton wrote: On 3/16/12 12:22 PM, Aleksey Khudyakov wrote: Disclaimer. I'm no expert in text internals. Because it's told to do so. This is an unfortunate feature of stream fusion. It does eliminate intermediate data structures but it requires that everything is inlined. There are ways of mitigating that, however. In particular, the standard style is to have things inline aggressively before stage 0 or 1, and then in the last stage to inline things back to an indirect call to the library. This is used ubiquitously in GHC's list fusion, and is essential for stream-fusion since the intermediate stream form is a pessimation when it can't partake in fusion. I've checked source. Many functions have RULES to remove unfused strings. pack however doesn't ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Too much inlining on text package
I suggest you file a bug. :) https://github.com/bos/text/issues -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Too much inlining on text package
On 17.03.2012 02:24, Johan Tibell wrote: I suggest you file a bug. :) I'm way too lazy for that. Also I don't want to steal joy of reporting a bug from people who actually suffer from it ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Too much inlining on text package
On Fri, Mar 16, 2012 at 3:48 PM, Aleksey Khudyakov alexey.sklad...@gmail.com wrote: On 17.03.2012 02:24, Johan Tibell wrote: I suggest you file a bug. :) I'm way too lazy for that. Also I don't want to steal joy of reporting a bug from people who actually suffer from it I meant you as in the collective you who care about this, not you specifically. :) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
