Re: Our change list for Lua 5.1work2

["Adam D. Moss" <adam@...>]

Roberto Ierusalimschy wrote:
> > I think I concluded from my mid-November fiddling that stepmul>2 is
> > *mostly* a red herring, and changing the threshold growth factor as
> > above is a more effective way of restricting memory growth).
>
> We are mostly blind in this area. It would be a good idea to fix
> stepmul as 2 and set a variable multiplier for the estimate? Something
> like
>
>   g->GCthreshold = (g->estimate/1024) * g->someValue;

That was my first thought, yes.  However, it's pretty hard
for users to tune magic numbers like this without knowing
at least a little about the effect they have, so they will
know the point at which their program's demands are likely
to cause the need for a re-tuning session.  It would help
enormously if there were an explanation as simple as 'this
value should be 1024 times 120% times the estimated
ratio of new objects to dead objects within your program
over a given period' (n.b. I don't know if this is related
to what this magic number actually does -- it's just an
example).

Come to think of it though, articulating any such hint
probably describes how Lua's implementation could derive
such a value automatically, removing the need for the tunable
in the first place. :)

But I think there's probably always a case to be made for
letting the user tune things like 'speed vs. peak memory usage',
assuming that these tradeoffs always exist.  That's a more
obvious thing to tune than these more obscure magic numbers,
but without exposing the magic numbers first it's hard to
tell which ones are going to have an affect in which direction,
and then we're still guessing about whether a tuning which
applies to one application will be good for another.

--Adam
PS: I don't generally like tunables, but this isn't a perfect
world. :/