lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Mike Pall wrote:
Umm, no. Another stack drives up complexity. We already have two
semi-synchronous stacks (TValue stack and Callinfo aka the frame
stack). I've gotten rid of Callinfo completely in LuaJIT 2.x -- it
improved performance remarkably and simplified many code paths.

Hmm, not sure I agree that a second, rarely used, stack would complicate anything more then the current varargs-between-frames. Working on the old principle of optimizing the most common case, it allows simplifying CI usage in at least one way I can think of. Remove ci->func, and the running function is always at L->base-1. (I imagine jit 2.x simplifies the whole structure down to 8-16 bytes in ways I cannot see however.) Keep the vararg top/bottom references as numbers in the stack so CI doesn't get bloated to aid rarely used vararg functions. I am open to that it would bloat lua_State a little more though, and possibly introduce more rare bugs that only apply to vararg functions..

Mike Pall wrote:
Introducing another stack/queue is certainly not the way to go.
First you have to put in all the magic to make the compiler
recognize the append/prepend cases to keep them O(1). And then you
have to implement a data structure that can efficiently grow on
either side and still avoid pathological unbounded growth. And you
somehow need to attach it to the current frame and keep many of
these data structures at once for all vararg frames. Ugh ...

Append/prepend are easy enough to detect - they only occur when the last instruction was a vararg, just combine that with the set vararg op. The second stack/queue need only grow in one direction. The values would have to be stored "upside down", such that:

varargfunc(1, 2, 3)

base -> 3, 2, 1

Removing the front merely increments base, Adding an element to the front of the list simply adds to top. Exiting a vararg function just restores the previous base and top. It is true that there would be unbound growth if used in a very unusual fashion, but not really a problem imo.

This probably looks like line-noise for anyone not as deep into
Lua as you and me. It's very unlikely that '...' as an lvalue is a
concept that can be easily comprehended and safely used. Without
an efficient append-at-front this would be O(n^2) again. I'm not
sure you want to write the docs explaining all the cases that do
lead to degenerate behaviour and those that don't.

Despite arguing that it wouldn't be that complicated (I really don't believe it would), I agree here. Although it's original intended uses still seem clearer to me then the alternative of creating skip2 function wrappers, I thought I'd entertain a few ways to abuse it which allow things Lua currently doesn't :). I only really bumped the post because of how efficiently it allows writing unpack. I particularly like any feature that requires some current functions to be written in C to be effective.

It probably worked more as a counter-argument then a for-argument however.

apairs() would be a simple 10-line addition to the standard
library and requires no changes to the Lua core.

That's true, I've got an apairs as part of my own base library. Useful for the rare varargs function you write..

Sorry for the noise :)

- Alex