RE: [Haskell] Excessive sharing and GHC
| Clearly, in this instance GHC is not transforming either of these | definitions into the other. But are there other compile time transformations | performed by GHC that might result in more (excessive) sharing, in | particular the creation of new common sub-expressions such as pxs? If not, | is that a deliberate design decision? GHC tries not to create space leaks, but does not guarantee not to. In particular, the full laziness transformation is so beneficial most of the time that, even though it can create a space leak GHC still does it (unless you turn it off with a flag). GHC only does very limited common sub-expression elimination, which again is very beneficial usually but can have bad behaviour. It's not general CSE which is why it didn't kick in in the program you gave. | Since I guess the "excessive" bit of excessive sharing probably can't be | determined until run-time, would it be practical for the run-time system to | do something about it? For example, once the run-time system notices that | the graph size has breached a certain threshold it begins to decouple | references to "reduced" but bulky sections of the graph, forcing them to be | recomputed (from the original expression) at a later time. I don't know anyone who has tried to make this work. Sounds pretty tricky. Simon
On Tue, Oct 18, 2005 at 08:31:19AM +0100, Simon Peyton-Jones wrote:
GHC tries not to create space leaks, but does not guarantee not to. In particular, the full laziness transformation is so beneficial most of the time that, even though it can create a space leak GHC still does it (unless you turn it off with a flag).
I was thinking it would be nice if one could put a pragma on CAFs that basically made ghc treat them as WHNF so it would float them inward as far as possible including inside lambdas. in particular, constant strings that are created (cheaply) from efficient internal representations should not be held onto in their inefficient form. it might even be worth it to have a pragma that made ghc think they were duplicatable too, so it would float them all the way to each of their uses, duplicating the expression as necessary just to make sure it is never held onto more than needed. John -- John Meacham - ⑆repetae.net⑆john⑈
John Meacham wrote:
On Tue, Oct 18, 2005 at 08:31:19AM +0100, Simon Peyton-Jones wrote:
GHC tries not to create space leaks, but does not guarantee not to. In particular, the full laziness transformation is so beneficial most of the time that, even though it can create a space leak GHC still does it (unless you turn it off with a flag).
I was thinking it would be nice if one could put a pragma on CAFs that basically made ghc treat them as WHNF so it would float them inward as far as possible including inside lambdas. in particular, constant strings that are created (cheaply) from efficient internal representations should not be held onto in their inefficient form.
What about adding a unit argument? That would do the trick without pragmas. All the best, -- Daan
it might even be worth it to have a pragma that made ghc think they were duplicatable too, so it would float them all the way to each of their uses, duplicating the expression as necessary just to make sure it is never held onto more than needed.
John
On Wed, Oct 19, 2005 at 12:01:07AM +0200, Daan Leijen wrote:
John Meacham wrote:
On Tue, Oct 18, 2005 at 08:31:19AM +0100, Simon Peyton-Jones wrote:
GHC tries not to create space leaks, but does not guarantee not to. In particular, the full laziness transformation is so beneficial most of the time that, even though it can create a space leak GHC still does it (unless you turn it off with a flag).
I was thinking it would be nice if one could put a pragma on CAFs that basically made ghc treat them as WHNF so it would float them inward as far as possible including inside lambdas. in particular, constant strings that are created (cheaply) from efficient internal representations should not be held onto in their inefficient form.
What about adding a unit argument? That would do the trick without pragmas.
I believe that full-lazyness will still take the body of the routine and float it to the top as a CAF. as in if we have foo () = fromPackedString big_string then the (fromPackdString big_string) will be floated out by the standard full lazyness transform (as I understand it) John -- John Meacham - ⑆repetae.net⑆john⑈
participants (3)
-
Daan Leijen -
John Meacham -
Simon Peyton-Jones