Re: [ANN] Ravi (a Lua 5.3 dialect) with LLVM JIT Compilation technology - Alpha Release 0.12

[Dibyendu Majumdar <mobile@...>]

Hi Simon,

On 9 December 2015 at 02:31, Simon Cozens <simon@simon-cozens.org> wrote:
>> Does SILE create a lot of Lua functions dynamically?
>
> No, but it does call the same very small functions hundreds of thousands
> of times. The most complex routines are in here:
>
> https://coveralls.io/builds/4385835/source?filename=core%2Fbreak.lua
>

I had a quick look at above. Sadly with code that is frequently
accesses deeply nested table structures is not very well handled in
Ravi - currently thee is no easy way to detect types when using such
constructs.

>> I'd be interested to know what auto options you tried out.
>
> I just did ravi.auto(true)

Thanks - that's good to know. If I get some time I will try running SILE myself.

>
>> So for best results the compiler needs to be helped by annotating
>> types.
>
> Ah. It's a shame there isn't a backward compatible way to do this. :(
> Could we not have a ravi.annotate() function which could be initialized
> to a dummy function in plain Lua?
>
> Also, I guess another problem is that SILE makes heavy use of objects -
> table elements rather than plain variables - and I can't see a way to
> annotate table members. i.e. I would like to be able to do:
>
> _length = std.object {
>   length : number = 0,
>   stretch : number = 0,
>   shrink : number = 0,
> }
>
> I've tried doing a few annotations, but without being able to annotate
> table members it all goes wrong quite quickly. e.g.:
>
>   local pi:integer
>   ...
>   pi = n.penalty or 0
>
> core/break.lua:101: Invalid assignment: integer expected near 'end'
>
> Actually n.penalty is an integer, but I can't annotate it as such.
>

Yes heavy use of tables as objects is problematic for Ravi as there is
no way to determine types when such constructs are used. I am looking
at a possible solution (see the thread
http://lua-users.org/lists/lua-l/2015-11/msg00124.html) but this is
not done yet.

>> Each Lua function goes into its own module (compilation unit) in LLVM
>> at present - this makes each function autonomous and therefore garbage
>> collectible - but this is not optimum usage of memory. I need to work
>> on putting multiple functions in a module; but this would mean that
>> the module cannot be collected until all functions in it are
>> collected.
>
> It would be helpful to be able to declare a bunch of functions as
> related. I tend to put related functions in a table for this purpose,
> and that's a pretty common object oriented programming style. So you
> might have a way to compile a table full of functions as a unit.
>

Thank you for the suggestion; I was thinking of the same thing after
getting your initial report.

Regards
Dibyendu