Re: Extending array types in Ravi

[Rena <hyperhacker@...>]

On Nov 4, 2015 4:21 PM, "Dibyendu Majumdar" <mobile@majumdar.org.uk> wrote:
>
> On 3 November 2015 at 13:26, Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
> >> One of the other enhancements I have been thinking about for a while
> >> is to efficiently support aggregate types. Mainly the idea I have been
> >> playing around with is to implement such types using tables - but with
> >> numeric indices. The reason for using a numeric index is to help
> >> generate efficient code. For example a 'get' operation could be
> >> inlined thus:
> >>
> >> if (l_castS2U(key - 1) < t->sizearray)
> >>     v = &t->array[key - 1];
> >> else
> >>     v = luaH_getint(t, key);
> >>
> >> The problem with numeric indices is readability and error-proneness.
> >> [...]
> >
> > Did you consider an inline expansion of short string keys? You could
> > do a loop unrolling of 'luaH_getstr'. (With 2 steps, I believe you
> > get a very high percentage of hits.) It is not the same as the
> > above expansion for integer keys, but it could be a reasonable
> > compromise.
> >
>
> No I hadn't considered that - thanks for the idea! If the parser knows
> that the variable is a table (static typing can tell it that) - and
> the key is a literal short string (which I believe the parser already
> knows from the fact that it is a constant) - then yes, it should be
> possible to generate inline code for the initial attempt to access the
> element - and failing that either try again as you suggest or fallback
> on calling the function luaH_getstr().
>
> Another thing that may help is if there was a way to make a table
> fixed in keys - i.e. notify that no further key updates are possible.
> This could be used by the table library to optimize the hash table so
> that all keys require only single access. I understood you are looking
> at this for another reason ... optimization of length operations - but
> there is probably also a benefit in scenarios such as here.
>
> Regards
>
Would it be enough to provide a "hint" function, that tells the interpreter "I probably won't be modifying this table['s keys] anymore, so if you could take a moment to do whatever you need to make reading from it as fast as possible, that'd be great"? Understanding that if you do modify the table afterward, it might be slow, and that the function might do nothing at all in some implementations.