Front page | perl.perl5.porters |
Postings from December 2021
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