Hi
Yes, though testing stackGobbler with a large enough data set could
be problematic for the very reason we've been discsussing.
Yes you are sure, or yes you tested and the results show than
neilGobbler is x% slower and consume y% more memory on specific test
n?
But let's say your
Hi
But the point is that *both* heapGobbler and neilGobbler are likely to
be slower and chew through at least twice as much heap as stackGobbler,
which would be the implementation of choice for both simplicity and
performance if it wasn't for this stack management problem.
Sure? That sounds
Adrian Hey wrote:
AFAICT neilGobbler isn't even entirely safe as an implementation of
an eager take. There's nothing the Haskell standard to stop it being
transformed into..
neilGobbler :: Int - [x] - [x]
neilGobbler n xs = length (take n xs) `seq` take n xs
Whoops, I see stackGobbler has the
Neil Mitchell wrote:
Hi
But the point is that *both* heapGobbler and neilGobbler are likely to
be slower and chew through at least twice as much heap as stackGobbler,
which would be the implementation of choice for both simplicity and
performance if it wasn't for this stack management problem.
Neil Mitchell wrote:
Hi
I have already partially scanned the list looking for the first
element that satisfies some condition, using a tail recursive search.
If such an element is found I want to split the list at that point.
span/break? I really can't believe the memory overhead of span is
Neil Mitchell wrote:
Hi
If you mean an example of coding style and choice of stack vs. heap,
I already have..
http://www.haskell.org/pipermail/haskell-cafe/2008-January/038832.html
I'm at a loss as why you want a strict version of take. It's clearly
not for performance, as it performs
Hi
I have already partially scanned the list looking for the first
element that satisfies some condition, using a tail recursive search.
If such an element is found I want to split the list at that point.
span/break? I really can't believe the memory overhead of span is that
terrible, you
| First bad thing:
| Stack size (memory consumed) doubles each time it overflows.
|
| Second bad thing:
| Arbitrary limit on stack size unrelated to overall (heap) memory
| available.
|
| Third bad thing (the really bad thing):
| If a stack has temporarily grown (to 64M say), it will never shrink
Stefan O'Rear wrote:
On Mon, Feb 04, 2008 at 10:13:12PM +, Adrian Hey wrote:
Also
remember that this behaviour never wastes more than 50% of the stack,
which is a relatively small amount.
Only if the stack is relatively small. Would you say the same about
heap, or about a stack that only
Simon Peyton-Jones wrote:
| First bad thing:
| Stack size (memory consumed) doubles each time it overflows.
|
| Second bad thing:
| Arbitrary limit on stack size unrelated to overall (heap) memory
| available.
|
| Third bad thing (the really bad thing):
| If a stack has temporarily grown (to 64M
| Yes, this is the standard solution, and it's a good one because it has a
robust cost model (no quadratic
| costs). However, it's tricky to get right; copying is simpler. If a
significant fraction of runtime (for some
| interesting program(s)) turned out to be consumed by copying stacks
Hello Matthew,
Monday, February 4, 2008, 11:45:51 PM, you wrote:
That would be nice. But its only beneficial if there are programs
which takes large amounts of stack at some point, but then shrink down
to very little stack and continue for a reasonable amount of time.
From the 'when I was a
On Feb 5, 2008 2:50 AM, Adrian Hey [EMAIL PROTECTED] wrote:
I think it bites a lot less often than it otherwise would because most
people will deliberately chose to use heap in preference to stack (at
least when writing eager code) just to avoid the problem. But it still
bites pretty often
On Feb 5, 2008 6:50 PM, Adrian Hey [EMAIL PROTECTED] wrote:
Luke Palmer wrote:
On Feb 5, 2008 2:50 AM, Adrian Hey [EMAIL PROTECTED] wrote:
I think it bites a lot less often than it otherwise would because most
people will deliberately chose to use heap in preference to stack (at
least
Hi
If you mean an example of coding style and choice of stack vs. heap,
I already have..
http://www.haskell.org/pipermail/haskell-cafe/2008-January/038832.html
I'm at a loss as why you want a strict version of take. It's clearly
not for performance, as it performs slower. I'd say both the
Bulat Ziganshin wrote:
Hello Matthew,
Monday, February 4, 2008, 11:45:51 PM, you wrote:
That would be nice. But its only beneficial if there are programs
which takes large amounts of stack at some point, but then shrink down
to very little stack and continue for a reasonable amount of time.
Hello Adrian,
Tuesday, February 5, 2008, 10:15:59 PM, you wrote:
i would be also happy if ghc will return unused *heap* memory back to
OS - it's immediately required for my GUI program where users may open
huge files and then close them. but i personally don't have the same
need for *stack*
Simon Peyton-Jones wrote:
| Yes, using lots of stack is clearly bad with ghc, but this is a ghc
| bug. In fact the only reason these programs do use lots of stack
| (vs. heap) is just a peculiarity of ghc rts implementation, so it
| really should be ghc that fixes the problem, or at least admits
| Sorry, but if what you say is true then things are even worse than I
| thought :-( This behaviour seems really bad to me, especially for
| concurrent programs.
Which behaviour precisely? Can you say what is wrong and what behaviour you
expect?
S
Hi
But if a program or library is deliberately designed to
make use of stack (in preference to heap) for efficiency reasons
then this is a source of bugs in otherwise perfectly correct and
reasonable programs.
Can you give an example of a particular library or program, so
everyone can be a
Hello Simon,
Simon Peyton-Jones wrote:
| Sorry, but if what you say is true then things are even worse than I
| thought :-( This behaviour seems really bad to me, especially for
| concurrent programs.
Which behaviour precisely? Can you say what is wrong and what behaviour you
expect?
Hi
First bad thing:
Stack size (memory consumed) doubles each time it overflows.
Bad thing? Assume that allocating memory takes some constant amount of
time, such as invoking overflow behaviour etc. To get the size of the
stack to n bytes with doubling takes O(log n), to get it there with a
On Monday 04 February 2008, Adrian Hey wrote:
Yikes!
Also, I can't help thinking that the common justification for the
current limit (that it helps find alleged bugs) is a little lame.
It only helps find bugs if one expects ones program to use less than
8M of stack (hence if it's using more,
On Monday 04 February 2008, Neil Mitchell wrote:
Hi
That would be nice. But its only beneficial if there are programs
which takes large amounts of stack at some point, but then shrink down
to very little stack and continue for a reasonable amount of time.
From the 'when I was a lad'
Neil Mitchell wrote:
Hi
First bad thing:
Stack size (memory consumed) doubles each time it overflows.
Bad thing? Assume that allocating memory takes some constant amount of
time, such as invoking overflow behaviour etc. To get the size of the
stack to n bytes with doubling takes O(log n), to
On Mon, Feb 04, 2008 at 10:13:12PM +, Adrian Hey wrote:
Also
remember that this behaviour never wastes more than 50% of the stack,
which is a relatively small amount.
Only if the stack is relatively small. Would you say the same about
heap, or about a stack that only needed 50% of heap
| Yes, using lots of stack is clearly bad with ghc, but this is a ghc
| bug. In fact the only reason these programs do use lots of stack
| (vs. heap) is just a peculiarity of ghc rts implementation, so it
| really should be ghc that fixes the problem, or at least admits
| responsibility :-)
I
Derek Elkins wrote:
While perhaps for a simple throw-away program it may be beneficial to
write code that allocates unnecessary stack, I personally consider
unnecessary stack use a bug. A stack overflow, to me, is always
indicative of a bug.
The bug is in ghc stack management. Why is it so
Hi Adrian,
The bug is in ghc stack management. Why is it so important that the
stack size is arbitrarily limited?
It's not, but it makes some things easier and faster. A better
question is why is it important for the stack to grow dynamically. The
answer is that its not.
It's just an
On 29 Jan 2008, at 1:28 AM, Neil Mitchell wrote:
Hi Adrian,
The bug is in ghc stack management. Why is it so important that the
stack size is arbitrarily limited?
It's not, but it makes some things easier and faster. A better
question is why is it important for the stack to grow
On Tue, Jan 29, 2008 at 07:38:24PM +, Neil Mitchell wrote:
A lot also depends on compiler (and associated rts), such as whether
or not it translates to CPS, thereby in effect building a stack (in
all but name) on the heap.
If you burn a lot of heap, for not much gain, that's still a
Jonathan Cast wrote:
http://www.cs.princeton.edu/~appel/papers/45.ps is the traditional cite
here, no?
Can be is not the same as is. A lot depends on exactly what you
call a stack and the relative efficiencies of stack vs. heap
implementations. Certainly my experience of library tuning tells
ndmitchell:
Hi
implementations. Certainly my experience of library tuning tells
me that (with ghc at least), designing your code and data structures
to keep heap allocation down to an absolute minimum is very important.
Yes. Keeping allocation low is very important, be it heap or
Hi
implementations. Certainly my experience of library tuning tells
me that (with ghc at least), designing your code and data structures
to keep heap allocation down to an absolute minimum is very important.
Yes. Keeping allocation low is very important, be it heap or stack.
Heap allocation
On Tue, Jan 29, 2008 at 09:28:56AM +, Neil Mitchell wrote:
Hi Adrian,
The bug is in ghc stack management. Why is it so important that the
stack size is arbitrarily limited?
It's not, but it makes some things easier and faster. A better
question is why is it important for the stack
Neil Mitchell wrote:
My claim is that any program which needs to adjust the stack size has
a laziness leak - since I've made a universally quantified claim, a
couple of real examples should blow it out of the water.
But people often deliberately introduce lazyness leaks for improved
efficency
On Tue, 2008-01-29 at 08:18 +, Adrian Hey wrote:
Derek Elkins wrote:
While perhaps for a simple throw-away program it may be beneficial to
write code that allocates unnecessary stack, I personally consider
unnecessary stack use a bug. A stack overflow, to me, is always
indicative of
Hi Istarex,
Does Haskell have a maximum stack depth restriction like Java
Python, or is it only limited by the maximum stack available on the
system (i.e. what would be available to a C program)?
You are probably thinking that recursive functions use up program
stack, and hence the stack
Hi all,
Does Haskell have a maximum stack depth restriction like Java
Python, or is it only limited by the maximum stack available on the
system (i.e. what would be available to a C program)?
Thanks,
Istarex
___
Haskell-Cafe mailing list
Hi
ghc uses a pretty conventional stack AFAIK, and it is arbitrarily
limited, but you can change the limit with +RTS options.
GHC uses a conventional stack (in that you put stuff at the top, and
take it off from the top), but it is not a conventional stack in the
way imperative programs work.
Neil Mitchell wrote:
Hi Istarex,
Does Haskell have a maximum stack depth restriction like Java
Python, or is it only limited by the maximum stack available on the
system (i.e. what would be available to a C program)?
You are probably thinking that recursive functions use up program
stack,
On Jan 28, 2008 1:07 PM, Neil Mitchell [EMAIL PROTECTED] wrote:
To answer the question if Haskell has a stack depth restriction ...
like Java the answer is no. It has a stack depth restriction, but its
absolutely nothing like Java in the way it uses the stack, so you
can't compare them.
Fair
On Mon, 2008-01-28 at 14:39 -0500, istarex wrote:
On Jan 28, 2008 1:07 PM, Neil Mitchell [EMAIL PROTECTED] wrote:
To answer the question if Haskell has a stack depth restriction ...
like Java the answer is no. It has a stack depth restriction, but its
absolutely nothing like Java in the
On 28 Jan 2008, at 10:07 AM, Neil Mitchell wrote:
Hi
ghc uses a pretty conventional stack AFAIK, and it is arbitrarily
limited, but you can change the limit with +RTS options.
GHC uses a conventional stack (in that you put stuff at the top, and
take it off from the top), but it is not a
On Mon, 28 Jan 2008, Jonathan Cast wrote:
Or, to put it another way, the bugs Java's stack overflow is designed
to catch are considered good style in Haskell.
I consider explicit recursion in Haskell as bad style. One should use
higher order functions like 'map', 'fold', 'filter' and so on
On 28 Jan 2008, at 11:00 PM, Henning Thielemann wrote:
On Mon, 28 Jan 2008, Jonathan Cast wrote:
Or, to put it another way, the bugs Java's stack overflow is designed
to catch are considered good style in Haskell.
I consider explicit recursion in Haskell as bad style. One should use
higher
46 matches
Mail list logo
