"S. Alexander Jacobson" <[EMAIL PROTECTED]> writes:
> On 6 Jun 2001, Carl R. Witty wrote:
>
> > "S. Alexander Jacobson" <[EMAIL PROTECTED]> writes:
> >
> > > For example w/ foldl:
> > >
> > > foldl + 0 [1..1]
> > > foldl (+) ((+) 0 1) [2..1]
> > > foldl (+) ((+) ((+) 0 1) 2) [3..1]
>
At 10:41 AM 6/8/2001 -0400, S. Alexander Jacobson wrote:
> > One portable way to implement a memoizing function in Haskell (if the
> > domain of the function is countable) is to lazily build a data
> > structure that contains the results of the function on every possible
> > argument. Then you e
On 6 Jun 2001, Carl R. Witty wrote:
> "S. Alexander Jacobson" <[EMAIL PROTECTED]> writes:
>
> > For example w/ foldl:
> >
> > foldl + 0 [1..1]
> > foldl (+) ((+) 0 1) [2..1]
> > foldl (+) ((+) ((+) 0 1) 2) [3..1]
> >
> > Can't the implementation notice that each iteration leads to a
>
Hi Claus,
I've had a look at this example in GHood, and you are right, nhc98
does seem to create several copies of v-in.
> import Observe
>
> foo1 m
>= take m (observe "v-out" v)
> where
>v = 1 : concat (map triple (observe "v-in" v))
>triple x = [x,x,x]
>
> main = pri
"S. Alexander Jacobson" <[EMAIL PROTECTED]> writes:
> For example w/ foldl:
>
> foldl + 0 [1..1]
> foldl (+) ((+) 0 1) [2..1]
> foldl (+) ((+) ((+) 0 1) 2) [3..1]
>
> Can't the implementation notice that each iteration leads to a
> larger closure and, if it is running out of space g
Tom Moertel wrote:
> Okay, then, what is the *right* way to reason about these things?
I will take the oppurtunity to advertise some recent work I have been
doing together with David Sands.
I think that the call-by-need lambda calculus is a very good starting
point for gaining intuition about
From: "Tom Moertel" <[EMAIL PROTECTED]>
> Okay, then, what is the *right* way to reason about these things?
(Non?-)strictly speaking, there is no *right* way to reason about
these things, as Haskell somehow seems to have neglected to acquire
a semantics (blush - even Java has one, kind of..). The
Tom Moertel wrote:
>
> Mark Tullsen wrote:
> >
> > You have to realize that Alastair Reid is one of the truly
> > great Haskell programmers on planet earth. I'm serious.
> > So, when he says "incredibly subtle space leak" I wouldn't
> > expect the solution to be simple.
>
> Whoops. Now don't I
> Alastair David Reid wrote:
> > Executive summary: David's program has an incredibly subtle space leak
> > in it (or I'm being incredibly dumb). I encourage the honchos (and
> > would be honchos) to have a look. Users of other compilers might give
> > it a shot too.
I think there have been sev
"Steinitz, Dominic J" wrote:
> I'd love it if someone could write a tutorial paper on space
> leaks.
I agree that would be very useful.
> Even with the explanations that have been provided, I find it
> difficult to understand why expressions get evaluated in a
> particular order and why garbage
Mark Tullsen wrote:
>
> You have to realize that Alastair Reid is one of the truly
> great Haskell programmers on planet earth. I'm serious.
> So, when he says "incredibly subtle space leak" I wouldn't
> expect the solution to be simple.
Whoops. Now don't I feel foolish.
> As far as I can t
Mark Tullsen <[EMAIL PROTECTED]> writes:
> You have to realize that Alastair Reid is one of the truly great
> Haskell programmers on planet earth. I'm serious. So, when he says
> "incredibly subtle space leak" I wouldn't expect the solution to be
> simple. As far as I can tell, your argument
I'd love it if someone could write a tutorial paper on space leaks. Even with the
explanations that have been provided, I find it difficult to understand why
expressions get evaluated in a particular order and why garbage collections happen at
a given point.
Dominic.
-
On Tue, 5 Jun 2001, Tom Moertel wrote:
> "Wojciech Moczydlowski, Jr" wrote:
> >
> Even so, your results suggest that nhc98 is doing something
> interesting. Does the memory usage remain constant even if you take 10
> or 100 times the number of elements? If so, perhaps nhc98 is smart
I was ju
Tom,
I noticed this post after I had just posted my own response.
You have to realize that Alastair Reid is one of the truly
great Haskell programmers on planet earth. I'm serious.
So, when he says "incredibly subtle space leak" I wouldn't
expect the solution to be simple. As far as I can t
"Wojciech Moczydlowski, Jr" wrote:
>
> How come then that the very program compiled under nhc98 evaluates without
> any problem, with memory usage below 1M during its execution?
My claim was that v (as defined) grew faster than it could be consumed,
not that (length (foo1 n)) couldn't be evaluat
Alastair David Reid wrote:
>
> Executive summary: David's program has an incredibly subtle space leak
> in it (or I'm being incredibly dumb). I encourage the honchos (and
> would be honchos) to have a look. Users of other compilers might give
> it a shot too.
>
> David Bakin <[EMAIL PROTECTED]
On Tue, 5 Jun 2001, Tom Moertel wrote:
> The reason that foo1 "leaks" space is because the middle of v grows
> faster than its head. So taking elements from v causes its in-memory
> footprint to grow. To see why this is the case, evaluate foo1 by hand:
>
> So the problem isn't Hugs but rather
This whole discussion seems strange...
Is laziness an operational or a semantic issue?
Why can't haskell implementations reduce some expressions to save space?
In particular, why can't haskell mark expressions that grow after
evaluation, and reduce them if too much space is being consumed.
For ex
Alastair David Reid wrote:
>
> Executive summary: David's program has an incredibly subtle space leak
> in it (or I'm being incredibly dumb). I encourage the honchos (and
> would be honchos) to have a look. Users of other compilers might give
> it a shot too.
> David Bakin wrote:
>
> Why is t
Executive summary: David's program has an incredibly subtle space leak
in it (or I'm being incredibly dumb). I encourage the honchos (and
would be honchos) to have a look. Users of other compilers might give
it a shot too.
David Bakin <[EMAIL PROTECTED]> writes:
> Why is there a space leak i
Why is there a space leak in foo1 but not in foo2?
(I.e., in Hugs Nov '99) foo1 eats cells (and eventually runs out) where foo2
doesn't. That is, if I do (length (foo1 100)) I eventually run
out of cells but (length (foo2 100)) runs fine (every GC returns basically
the same amount
I wrote: [...]
> I just tried the developer snapshot of STG Hugs, and [...]
> After fixing the *other* space leak that Malcolm Wallace noted,
> all the tests ran without a problem. [...]
> Problem solved! Thanks!
Forgot to mention: my "real" program -- the XML parser --
also runs without a spa
Simon Peyton-Jones <[EMAIL PROTECTED]> wrote:
> Consider the Data a branch. It'll be compiled to
> let t = build es
> siblings = fst t
> rest = snd t
> in ...
> In many implementations, until you evaluate 'rest', you'll
> keep the whole of 't'; which in turn c
Joe,
Have you tried any of the more powerful forms of heap-profiling,
beyond static tagging of producer/construction?
| My hypothesis is that 'deserialize' (the problematic function,
| called 'buildTree' in my earlier message) is building up
| a long chain of suspensions of the form
|
| s
Joe
I've not really looked at your code in detail, but this does
occur to me:
| -- deserialize builds a tree from a list of events;
| -- (deserialize . serialize) = id
| --
| -- This is the problematic function.
| --
| deserialize :: [Event a] -> Tree a
| deserialize events = head (fst (build ev
Oops! Never mind. I found!
Thnaks,
Bill
>From: Joe English <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Is there a space leak here?
>Date: Sat, 26 Feb 2000 16:27:47 -0800
>
>"Mark P Jones" <[EMAIL PROTECTED]> wrote:
>
> > Joe:
Where is the XML stuff??
Bill Halchin
>From: Joe English <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Is there a space leak here?
>Date: Sat, 26 Feb 2000 16:27:47 -0800
>
>"Mark P Jones" <[EMAIL PROTECTED]> wrote:
>
> > Joe:
Here's the test case...
The space profile for tests 2 and 3 look interesting;
there are n triangular "spikes" (where 'n' is the breadth
of the tree) that drop off sharply.
My hypothesis is that 'deserialize' (the problematic function,
called 'buildTree' in my earlier message) is building up
a l
"Mark P Jones" <[EMAIL PROTECTED]> wrote:
> Joe: As you've observed, the space behavior of Haskell
> programs is often very subtle, and hard to understand.
> I glanced quickly over your program but didn't see any
> immediate signs of problems. My first suggestion would
> be that you try using t
Hi.
Joe English writes:
> [...] ought to run in space bounded by the depth of the tree
> (which for XML documents is typically not very deep).
>
> This turns out not to be the case; testing with Hugs
> invariably fails with a "Garbage collection fails to
> reclaim sufficient space" on even
[Prompted by Sergey's message about the strange dates:
The mess in my headers is entirely my fault.
I have not had a chance to properly finish the
upgrades to this machines: internationalization and
the rest. Please forgive me for this mess]
On Tue,
| Both simulations run fine for small values of
| counter "n" but fail badly when "n" becomes big,
| 40,000 say. I happened to have a presentation
| on the subject of Hawk about two months ago, and
| the audience was not much impressed when they saw
| Hugs faili
On Sun, 6 Feb 2000, Joe English wrote:
> This turns out not to be the case; testing with Hugs
> invariably fails with a "Garbage collection fails to
> reclaim sufficient space" on even moderately sized
> documents (5000 nodes or so).
If I remember correctly, one of the past postings
Hello,
I'm trying to construct a Tree out of a list of XML parser events,
with something similar to the following:
data Event a =
StartTag a -- start-tag,
| Data a -- character data or empty tag
| EndTag -- end-tag,
35 matches
Mail list logo
