develooper Front page | perl.perl5.porters | Postings from December 2021

Re: "no snails"; or having signatured subs complain about @_

Thread Previous | Thread Next
From:
Nicholas Clark
Date:
December 9, 2021 16:40
Subject:
Re: "no snails"; or having signatured subs complain about @_
Message ID:
YbIxepDuqik6W0kH@etla.org
On Thu, Dec 09, 2021 at 04:29:13PM +0000, Paul "LeoNerd" Evans wrote:
> On Thu, 9 Dec 2021 15:01:21 +0000
> Dave Mitchell <davem@iabyn.com> wrote:

[there are other parts of this message that I need to think about.]

> > PS - my intention is that the args will just be left on the stack,
> > @_ / padsv[0] will never be populated, and OP_ARG* get their values
> > directly from the stack.
> 
> OK, that's a detail I hadn't been aware of before. Keeping the values on
> the stack does increase memory usage overall - I could imagine a
> heavily signature-based program would have a much larger stack during
> runtime than current programs do; in effect much more data would be
> stored in a single AV, rather than being distributed over several of
> them as they are now. That would have a knock-on effect of needing to
> Move() more values around when that stack gets grown, so we'd have to
> measure if the performance was still OK. Right now the "arguments stack"
> is effectively distributed over many small AVs so that grow-time
> problem doesn't come up as much.

I don't think that this reasoning about larger stacks really pans out as you
fear. Total memory usage should be approximately identical - if each
function takes $n parameters, and we are $m calls deep, we either have a
single block of memory $m * $n pointers large, or $n arrays allocated each
size $m

A single block is likely actually smaller (due to per-block malloc overhead)
and its cache locality might be slightly better. Steady state (which is
really what we need to worry about) there won't be any moving of the stack,
because it will grow to the maximum transient size needed.

(OK, except for crazy deep recursive code that doesn't have a consistent
idea of how far down the rabbit hole it needs to go)

Once the stack has grown large enough we eliminate the need to Move() any
function arguments, if we keep arguments on the stack. Whereas if we still
store arguments off somewhere to the side (in an array) each and every call
needs to be a Move(). It's that "death by a thousand cuts" of small moves
that we can avoid by leaving arguments on the stack.

Also, unlike *nix C code, I don't think that the perl internals forbid
chunked stacks*. So on subroutine entry (or any suitable nextstate, *I
think*), we could decide that if the stack is already too unwieldy, just to
push a new stack onto the stack of stacks. This might address the "deep
recursion" caveat above.

Nicholas Clark

* This is the thing that RISC OS did that I'm staggered that Symbian never
  cottoned on to.


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About