Re: Wadler space leak
On 07/11/2010 17:47, Jan Christiansen wrote: On 02.11.2010, at 10:20, Simon Marlow wrote: It's not really a question of priority, rather that we don't know of a good way to fix it! I would not have guessed that there exists a Haskell related problem that cannot immediately be fixed by the ghc headquarters ; ) If I understand correctly, the problem is to keep the selectors recognizable while still performing optimizations that might destroy the selector structure. In Bertram's example the resulting expression looked as follows. l : case q of (_, ys) - case ys of [] - [] _:zs - splitBy' p zs Is it correct that the selector is not recognizable in this case because the right hand side fo the outermost case expression is not a simple variable but a case expression? It is probably quite naive to assume that the problem can be solved by looking for a structure like case q of (_,ys) - e where ys is a free variable in e. There are probably cases where further optimizations prevent this. Or do I miss the real problem in identifying selectors? The problem is that a selector has to be an expression of the form case x of C y1 .. yn - yi for some i. The RTS contains pre-compiled selectors for values of i up to 16. The garbage collector recognises selectors where x is already evaluated, and replaces them with the value. So you can't do this for an arbitrary expression without generalising the mechanism. Perhaps you could annotate an arbitrary thunk to say something like I select field N from free variable x and then the GC could null out all fields except for N, as long as x was not required elsewhere. But this has other problems - apart from being a lot more complicated in terms of what information we attach to thunks and what the GC has to do, it doesn't immediately eliminate the constructor, only the unreferenced fields, so you could still get certain kinds of leak. There's another approach in Jan Sparud's paper here: http://portal.acm.org/citation.cfm?id=165196 although it's not clear that this interacts very well with inlining either, and it has a suspicious-looking side-effecting operation. It also looks like it creates a circular reference between the thunk and the selectors, which might hinder optimisations, and would probably also make things slower (by adding extra free variables to the thunk). I haven't given it a great deal of thought though, maybe it could be made to work in GHC. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Loop optimisation with identical counters
On 6 November 2010 04:47, David Peixotto d...@rice.edu wrote: Are you sure about R1 aliasing Sp? AFAIK, R1 points to a closure on the heap, not to a stack location. That is, it can alias pointers on the stack or Hp but it can't alias the Sp itself. I don't think Sp can be aliased by anything outside of the garbage collector. Perhaps we shouldn't mark Hp as noalias, though. Well, I'm not sure about R1 aliasing with Sp. I thought that there could be some cases where closures are allocated on the stack, but I could be wrong. I think the stack should still be reachable by the garbage collector though. Can someone more familiar with GHC internals say whether R1 could point to the stack as well as the heap? GHC marks some closures as let-no-escapes which means that they get stack allocated. So AFAIK R1 may alias pointers based on SP. Cheers, Max ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: change in overlapping instance behavior between GHC 6.12 and GHC 7 causes compilation failure
Hello,
I have narrowed this down further to a single file. And created a trac
bug for it:
http://hackage.haskell.org/trac/ghc/ticket/4485
This is (the only thing?) holding up HSP and happstack moving to GHC 7.
- jeremy
On Tue, Nov 2, 2010 at 5:36 PM, Jeremy Shaw jer...@n-heptane.com wrote:
Hello,
I have a module, XMLGenerator, which has some overlapping instances.
I have a second module, Test, which imports that module and also adds
some more overlapping instances.
Both modules contain {-# LANGUAGE OverlappingInstances #-} at the top.
Under some old version of 6.13 (and probably 6.12), if I put both
modules in the same directory and try to load Test.hs, it gets the
error:
Test.hs:16:15:
Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
arising from a use of `asChild' at Test.hs:16:15-21
Matching instances:
instance (m1 ~ m, EmbedAsChild m c) =
EmbedAsChild m (XMLGenT m1 c)
-- Defined at XMLGenerator.hs:16:10-68
instance (XML m ~ x, XMLGen m) = EmbedAsChild m x
-- Defined at XMLGenerator.hs:19:10-51
In the first argument of `($)', namely `asChild'
In the expression: asChild $ (genElement foo)
In the definition of `asChild':
asChild b = asChild $ (genElement foo)
If I put the XMLGenerator module in a separate package, dummy-hsx, and
the Test modules links against it, I still get the error.
*but* if I add:
Extensions: OverlappingInstances
to the dummy-hsx.cabal file, then Test.hs compiles just fine! So, for
starters, I do not understand why that happens.
Under GHC 7.0rc1, modifying the .cabal file has no effect. Instead I
always get the error:
Test.hs:16:15:
Overlapping instances for EmbedAsChild (M IO) (XMLGenT m (XML m))
arising from a use of `asChild'
Matching instances:
instance [overlap ok] (m1 ~ m, EmbedAsChild m c) =
EmbedAsChild m (XMLGenT m1 c)
-- Defined in XMLGenerator
(The choice depends on the instantiation of `m'
To pick the first instance above, use -XIncoherentInstances
when compiling the other instance declarations)
Adding the IncoherentInstances flag does make it compile -- but I have
never enabled that flag and not regretted it.
What changed between GHC 6.12 and GHC 7.0? Is there a some solution
besides using IncoherentInstances in every module that imports
XMLGenerator?
I have attached XMLGenerator.hs, Test.hs, and dummy-hsx.cabal.
thanks!
- jeremy
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: new-www
On Mon, Nov 1, 2010 at 4:10 AM, Brent Yorgey byor...@seas.upenn.edu wrote: On Sat, Oct 30, 2010 at 01:08:50PM +0400, Serge D. Mechveliani wrote: People, what is, in short, the relation between www.haskell.org and new-www.haskell.org ? Which one do I need to use for looking for the Haskell materials, for GHC materials? As far as I can tell, new-www is just a sample mock-up of a potential new design for www.haskell.org. If you look carefully you will note that all the events listed at new-www are old. www.haskell.org is and will continue to be the place to go. new-www has the release directories for the ghc7 release candidates, such as http://new-www.haskell.org/ghc/dist/7.0.1-rc2/. These are not present on www. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Wadler space leak
On 8 November 2010 13:28, Simon Marlow marlo...@gmail.com wrote: There's another approach in Jan Sparud's paper here: http://portal.acm.org/citation.cfm?id=165196 although it's not clear that this interacts very well with inlining either, and it has a suspicious-looking side-effecting operation. It also looks like it creates a circular reference between the thunk and the selectors, which might hinder optimisations, and would probably also make things slower (by adding extra free variables to the thunk). This proposal is mentioned favourably by Jörgen Gustavsson David Sands in [1] (see section 6, case study 6). They mention that there is a formalisation in Gustavsson's thesis [2]. That may say something about inlining, since that's just the kind of transformation they'd want to show is a space improvement. [1]: Possibilities and Limitations of Call-by-Need Space Improvement (2001) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.8.4097 [2]: Space-Safe Transformations and Usage Analysis for Call-by-Need Languages (2001) (which I cannot immediately find online) Duncan ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
