
I have added a section "Ticky-ticky quick start" to our ticky-ticky profiling page, to explain how I go about dealing with the problem you describe
https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky
Simon
| -----Original Message-----
| From: David Feuer [mailto:david.feuer@gmail.com]
| Sent: 20 August 2014 09:33
| To: Simon Peyton Jones
| Subject: Re: Fusion
|
| I'll be happy to try to expand it with some examples. I'm wondering if
| you could help me figure something out: the (simple) cons/build rule
| we discussed, along with the similar cons/augment rule,
|
| "cons/build" forall (x::a) (g::forall b . (a->b->b)->b->b) . x :
| build g = build (\c n -> c x (g c n))
| "cons/augment" forall (x::a) (g::forall b . (a->b->b)->b->b)
| (xs::[a]) . x : augment g xs = augment (\c n -> c x (g c n)) xs
|
| somehow *increase* allocation substantially (11.7%) in the "event"
| NoFib test, and also significantly (3.6%) in constraints, somewhat
| (2.4%) in nucleic2 [remember this] and 1.4% in ansi. I am having a
| heck of a time trying to figure out how to track these down, and
| burning loads of time recompiling GHC over and over again. On the flip
| side of things, the wang test reduces allocation by 45.8% if I use
| these rules (both of which fire), but only when I also use -fsimple-
| list-literals for nofib/spectral/hartel/nucleic2/Main.hs.
| nucleic2 still performs a little more allocation.
|
| On Wed, Aug 20, 2014 at 2:56 AM, Simon Peyton Jones
|

Thank you! I will dig into using that ASAP now that I can understand the
directions.
On Aug 29, 2014 5:50 AM, "Simon Peyton Jones"
I have added a section "Ticky-ticky quick start" to our ticky-ticky profiling page, to explain how I go about dealing with the problem you describe https://ghc.haskell.org/trac/ghc/wiki/Debugging/TickyTicky
Simon
| -----Original Message----- | From: David Feuer [mailto:david.feuer@gmail.com] | Sent: 20 August 2014 09:33 | To: Simon Peyton Jones | Subject: Re: Fusion | | I'll be happy to try to expand it with some examples. I'm wondering if | you could help me figure something out: the (simple) cons/build rule | we discussed, along with the similar cons/augment rule, | | "cons/build" forall (x::a) (g::forall b . (a->b->b)->b->b) . x : | build g = build (\c n -> c x (g c n)) | "cons/augment" forall (x::a) (g::forall b . (a->b->b)->b->b) | (xs::[a]) . x : augment g xs = augment (\c n -> c x (g c n)) xs | | somehow *increase* allocation substantially (11.7%) in the "event" | NoFib test, and also significantly (3.6%) in constraints, somewhat | (2.4%) in nucleic2 [remember this] and 1.4% in ansi. I am having a | heck of a time trying to figure out how to track these down, and | burning loads of time recompiling GHC over and over again. On the flip | side of things, the wang test reduces allocation by 45.8% if I use | these rules (both of which fire), but only when I also use -fsimple- | list-literals for nofib/spectral/hartel/nucleic2/Main.hs. | nucleic2 still performs a little more allocation. | | On Wed, Aug 20, 2014 at 2:56 AM, Simon Peyton Jones |
wrote: | > Great start, thank you. Can I suggest that for each question you | give | > a concrete example? Otherwise only experts, who already know a lot | about | > rules, will understand the question, let alone the answer. I’d be | happy to | > take another look then. | > | > | > Simon | > | > | > | > From: David Feuer [mailto:david.feuer@gmail.com] | > Sent: 19 August 2014 23:30 | > To: Simon Peyton Jones | > Cc: Haskell Libraries | > Subject: Re: Fusion | > | > | > | > I've started a page at | > https://ghc.haskell.org/trac/ghc/wiki/FoldrBuildNotes | > Please feel free to add, correct, etc. | > | > On Aug 19, 2014 3:10 AM, "Simon Peyton Jones" | wrote: | > | > David | > | > You've been doing all this work on improving fusion, and you | probably | > have a very good idea now about how it works, and how GHC's | libraries | > use phases and RULES to achieve it. A kind of design pattern, if you | > like; tips and tricks. | > | > I wonder if you'd feel able to write a GHC wiki page describing what | > you have learned, with examples and explanation about why it is done | that way. | > If you did this, someone who follows in your footsteps wouldn't need | > to re-learn everything. And maybe someone will say "oh, there's one | > pattern you have omitted, here it is". | > | > Thanks | > | > Simon
participants (2)
-
David Feuer
-
Simon Peyton Jones