Re: [Boston.pm] Perl and recursion

2013-04-10 Thread Gyepi SAM
On Tue, Apr 09, 2013 at 10:24:45PM -0400, Bob Rogers wrote: map should produce better code and does reads better but it also iterates the entire list and you can't break out of it . . . Not quite true, as you can goto a label outside of the block: sub find_odd { # Return

Re: [Boston.pm] Perl and recursion

2013-04-10 Thread Bob Rogers
From: Gyepi SAM gy...@praxis-sw.com Date: Wed, 10 Apr 2013 13:54:06 -0400 On Tue, Apr 09, 2013 at 10:24:45PM -0400, Bob Rogers wrote: Not quite true, as you can goto a label outside of the block: [first example omitted] Indeed, you are correct. However, when you break

Re: [Boston.pm] Perl and recursion

2013-04-10 Thread Ben Tilly
On Wed, Apr 10, 2013 at 1:53 PM, Bob Rogers rogers-...@rgrjr.dyndns.org wrote: From: Gyepi SAM gy...@praxis-sw.com Date: Wed, 10 Apr 2013 13:54:06 -0400 On Tue, Apr 09, 2013 at 10:24:45PM -0400, Bob Rogers wrote: [...] Because your example handles a single result, it is not clear

Re: [Boston.pm] Perl and recursion

2013-04-10 Thread Bob Rogers
From: Ben Tilly bti...@gmail.com Date: Wed, 10 Apr 2013 14:09:19 -0700 On Wed, Apr 10, 2013 at 1:53 PM, Bob Rogers rogers-...@rgrjr.dyndns.org wrote: I would hope (but don't know how to check) that Perl is smart enough to notice that the map in my original example is in a void

Re: [Boston.pm] Perl and recursion

2013-04-09 Thread Bob Rogers
From: Gyepi SAM gy...@praxis-sw.com Date: Mon, 8 Apr 2013 15:02:55 -0400 On Mon, Apr 08, 2013 at 10:54:47AM -0400, Ricker, William wrote: Have we mentioned the other solution? The Implicit loops of map {block} list; should produce more optimized code and reads better too.

Re: [Boston.pm] Perl and recursion

2013-04-08 Thread David Cantrell
On Fri, Apr 05, 2013 at 09:20:16PM -0400, Jerrad Pierce wrote: Regardless, my understanding was that although perl's sub calls are somewhat expensive ... I think it's *method calls* that are expensive, not subroutine calls. The reason being that the subroutine that a method resolves to can

Re: [Boston.pm] Perl and recursion

2013-04-08 Thread Adam Russell
On Fri, Apr 5, 2013 at 8:22 PM, Jerrad Pierce belg4...@pthbb.org wrote: at each level of recursion. What seems to be the case though is that when we start going bac up the stack that memory doesn't seem to be released at each pop. If, say, at max depth 500mb of ram has been allocated I

Re: [Boston.pm] Perl and recursion

2013-04-06 Thread David Larochelle
Are languages that have mark and sweep garbage collection better about returning memory to the system than languages like Perl that use reference count garbage collection. Also if you really want to see how and why Perl is using memory, take a look at Tim Bunce's

Re: [Boston.pm] Perl and recursion

2013-04-06 Thread John Redford
David Larochelle writes: Are languages that have mark and sweep garbage collection better about returning memory to the system than languages like Perl that use reference count garbage collection. Not in practice. While that potential is there, in it is not utilized. Most programs that

Re: [Boston.pm] Perl and recursion

2013-04-06 Thread Gyepi SAM
On Sat, Apr 06, 2013 at 09:11:55AM -0400, David Larochelle wrote: Are languages that have mark and sweep garbage collection better about returning memory to the system than languages like Perl that use reference count garbage collection. Not usually. On Unix systems, at least, memory is

Re: [Boston.pm] Perl and recursion

2013-04-06 Thread Bill Ricker
On Sat, Apr 6, 2013 at 12:20 AM, Conor Walsh c...@adverb.ly wrote: Ah! Ok, so maybe I was confused about this. Even if I set the last reference to an object to undef perl will keep the memory until exit? The high water mark for memory usage never goes down? Well, that is fine I suppose, it

Re: [Boston.pm] Perl and recursion

2013-04-06 Thread Ben Tilly
On Fri, Apr 5, 2013 at 8:22 PM, Jerrad Pierce belg4...@pthbb.org wrote: at each level of recursion. What seems to be the case though is that when we start going bac up the stack that memory doesn't seem to be released at each pop. If, say, at max depth 500mb of ram has been allocated I don't see

Re: [Boston.pm] Perl and recursion

2013-04-06 Thread Bill Ricker
On Sat, Apr 6, 2013 at 12:30 PM, Bill Ricker bill.n1...@gmail.com wrote: On Sat, Apr 6, 2013 at 12:20 AM, Conor Walsh c...@adverb.ly wrote: Ah! Ok, so maybe I was confused about this. Even if I set the last reference to an object to undef perl will keep the memory until exit? The high water

Re: [Boston.pm] Perl and recursion

2013-04-06 Thread Uri Guttman
On 04/06/2013 10:30 AM, John Redford wrote: David Larochelle writes: Are languages that have mark and sweep garbage collection better about returning memory to the system than languages like Perl that use reference count garbage collection. Programs that want to do this kind of thing --

Re: [Boston.pm] Perl and recursion

2013-04-06 Thread John Redford
Uri Guttman writes: mmap won't help with returning ram to the system. there is still a malloc/free involved and that will come from the same place as the rest of ram. the only way to return virtual ram is by lowering the top virtual address with brk()/sbrk() calls. and that needs contiguous

[Boston.pm] Perl and recursion

2013-04-05 Thread Adam Russell
I am currently in the midst of implementing a fairly non-trivial recursive algorithm in Perl. The depth of the recursion is quite large, so much so that I have set no warning recursion which warns with a depth over 100. This seems pretty small to me! If the default is to warn at a depth of 100

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Conor Walsh
On Apr 5, 2013 8:24 PM, Uri Guttman u...@stemsystems.com wrote: as for your ram usage, all recursions can be unrolled into plain loops by managing your own stack. this is a classic way to save ram and sub call overhead. with perl it would be a fairly trivial thing to do. use an array for the

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Ben Tilly
On Fri, Apr 5, 2013 at 6:03 PM, Conor Walsh c...@adverb.ly wrote: On Apr 5, 2013 8:24 PM, Uri Guttman u...@stemsystems.com wrote: as for your ram usage, all recursions can be unrolled into plain loops by managing your own stack. this is a classic way to save ram and sub call overhead. with

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Conor Walsh
Detailed? What's kept beyond a called b (arguments...) ? That's not a lot of bytes, unless it's complete deep copies of structures. -C. On Apr 5, 2013 9:08 PM, Ben Tilly bti...@gmail.com wrote: On Fri, Apr 5, 2013 at 6:03 PM, Conor Walsh c...@adverb.ly wrote: On Apr 5, 2013 8:24 PM, Uri

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Jerrad Pierce
Detailed? What's kept beyond a called b (arguments...) ? That's not a lot of bytes, unless it's complete deep copies of structures. perldoc -f caller package, line number, etc. Regardless, my understanding was that although perl's sub calls are somewhat expensive to some other languages that

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Bill Ricker
THEORY Ever general computer science over-simplification has a BUT that is very important. Recursion is as efficient as iteration ... ... IF AND ONLY IF Tail Recursion Optimization is in effect. When Tail Recursion is in effect, you do NOT have all that call stack, you're only one level down

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Ben Tilly
On Fri, Apr 5, 2013 at 6:39 PM, Bill Ricker bill.n1...@gmail.com wrote: THEORY Ever general computer science over-simplification has a BUT that is very important. Recursion is as efficient as iteration ... ... IF AND ONLY IF Tail Recursion Optimization is in effect. When Tail Recursion is

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Bill Ricker
On Fri, Apr 5, 2013 at 9:51 PM, Ben Tilly bti...@gmail.com wrote: When in doubt, benchmark. I always doubt my benchmarks. I also doubt benchmarks, but doubt extrapolating from theory to reality even more. -- Bill @n1vux bill.n1...@gmail.com

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Gyepi SAM
On Fri, Apr 05, 2013 at 09:03:13PM -0400, Conor Walsh wrote: why is this that much faster than actual recursion? That speaks poorly of lowercase-p perl. This is not a perl specific issue (for the most part). Most languages that support function calls need to maintain an activation record for

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Greg London
function calls are relatively expensive. Certainly more so than iteration or array operations. Maybe we could get a new pragma: no overhead 'subs'; ;/ I've been fighting a perl script problem for a while now and just recently figured out a potential solution that just happens to involve a

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Adam Russell
Date: Fri, 05 Apr 2013 20:23:30 -0400 From: Uri Guttman u...@stemsystems.com To: boston-pm@mail.pm.org Subject: Re: [Boston.pm] Perl and recursion Message-ID: 515f6b02.70...@stemsystems.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 04/05/2013 08:13 PM, Adam Russell wrote: I

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Jerrad Pierce
at each level of recursion. What seems to be the case though is that when we start going bac up the stack that memory doesn't seem to be released at each pop. If, say, at max depth 500mb of ram has been allocated I don't see that released at any point except for when perl exits and then of

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Uri Guttman
On 04/05/2013 11:22 PM, Jerrad Pierce wrote: at each level of recursion. What seems to be the case though is that when we start going bac up the stack that memory doesn't seem to be released at each pop. If, say, at max depth 500mb of ram has been allocated I don't see that released at any

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Adam Russell
at each level of recursion. What seems to be the case though is that when we start going bac up the stack that memory doesn't seem to be released at each pop. If, say, at max depth 500mb of ram has been allocated I don't see that released at any point except for when perl exits and then

Re: [Boston.pm] Perl and recursion

2013-04-05 Thread Conor Walsh
On 4/6/2013 12:01 AM, Adam Russell wrote: Ah! Ok, so maybe I was confused about this. Even if I set the last reference to an object to undef perl will keep the memory until exit? The high water mark for memory usage never goes down? Well, that is fine I suppose, it isn't like this process will