What's upcoming with Ravi

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

What's upcoming with Ravi

Dibyendu Majumdar
Hi,

I thought I will give a quick update on what's happening with Ravi.

Here are the things I am working on:

1. A Ravi distribution
(https://github.com/dibyendumajumdar/ravi-distro); working on
documentation
2. Generational GC from Lua 5.4 - this is mostly done but I am waiting
for Lua 5.4 final release to complete this.
3. Some other changes in Lua 5.4 will be merged.
4. A new parser / code generator is being worked on. So far only got
to AST stage.
5. The dmrC C parser is now included in Ravi.
6. A new JIT backend based on OMR JIT technology will be worked on
after I have integrated this with the dmrC front-end.
7. A new way of defining C functions (via api) that allows fast direct
calls to C functions that take primitive or pointer arguments (will
only support specific argument/return value combinations). This
bypasses the standard Lua mechanism for calling C functions.
8. Faster memory allocation by integrating Doug Lea's malloc library.

So many things being worked on in parallel but I don't have timescales
for a release.


Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: What's upcoming with Ravi

Soni "They/Them" L.


On 2018-06-23 02:16 PM, Dibyendu Majumdar wrote:

> Hi,
>
> I thought I will give a quick update on what's happening with Ravi.
>
> Here are the things I am working on:
>
> 1. A Ravi distribution
> (https://github.com/dibyendumajumdar/ravi-distro); working on
> documentation
> 2. Generational GC from Lua 5.4 - this is mostly done but I am waiting
> for Lua 5.4 final release to complete this.
> 3. Some other changes in Lua 5.4 will be merged.
> 4. A new parser / code generator is being worked on. So far only got
> to AST stage.
> 5. The dmrC C parser is now included in Ravi.
> 6. A new JIT backend based on OMR JIT technology will be worked on
> after I have integrated this with the dmrC front-end.
> 7. A new way of defining C functions (via api) that allows fast direct
> calls to C functions that take primitive or pointer arguments (will
> only support specific argument/return value combinations). This
> bypasses the standard Lua mechanism for calling C functions.
> 8. Faster memory allocation by integrating Doug Lea's malloc library.
>
> So many things being worked on in parallel but I don't have timescales
> for a release.
>
>
> Regards
> Dibyendu
>

Nice.

Would it be possible to implement CC-JIT support?

Reply | Threaded
Open this post in threaded view
|

Re: What's upcoming with Ravi

Dibyendu Majumdar
On 23 June 2018 at 20:51, Soni "They/Them" L. <[hidden email]> wrote:
> Would it be possible to implement CC-JIT support?
>

If you mean compiling with external compiler then yes I suppose so,
but that would mean creating some kind of shared library and loading
code from that ... pretty inefficient.

Regards

Reply | Threaded
Open this post in threaded view
|

Re: What's upcoming with Ravi

Philipp Janda
In reply to this post by Dibyendu Majumdar
Am 23.06.2018 um 19:16 schröbte Dibyendu Majumdar:
> Hi,

Hi!

> 8. Faster memory allocation by integrating Doug Lea's malloc library.

Are you sure that dlmalloc is actually faster than the native libc
malloc? It's a great piece of software for sure but a few decades old by
now. libc implementors have had ample time to catch up (or at least
integrate dlmalloc into their own code -- it's public domain software
after all).

>
> Regards
> Dibyendu

Philipp



Reply | Threaded
Open this post in threaded view
|

Re: What's upcoming with Ravi

Dibyendu Majumdar
On 23 June 2018 at 21:56, Philipp Janda <[hidden email]> wrote:
>> 8. Faster memory allocation by integrating Doug Lea's malloc library.
>
> Are you sure that dlmalloc is actually faster than the native libc malloc?
> It's a great piece of software for sure but a few decades old by now. libc
> implementors have had ample time to catch up (or at least integrate dlmalloc
> into their own code -- it's public domain software after all).
>

In my tests yet. Gains are more on Windows than on Linux.

DL malloc has a arena option / and locking / thread local access can
be disabled as Lua is single threaded. You can't switch off those
features in a generic malloc.

BTW note that LuaJIT also uses the same arena feature - with small
customizations for dealing with memory start address etc. But
essentially it is DL malloc arena code.

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: What's upcoming with Ravi

Sean Conner
In reply to this post by Dibyendu Majumdar
It was thus said that the Great Dibyendu Majumdar once stated:
> On 23 June 2018 at 20:51, Soni "They/Them" L. <[hidden email]> wrote:
> > Would it be possible to implement CC-JIT support?
>
> If you mean compiling with external compiler then yes I suppose so,
> but that would mean creating some kind of shared library and loading
> code from that ... pretty inefficient.

  There's always TCC [1], a library which can compile code into memory that
can be called directly.  I have a Lua wrapper for it [2] and code on top of
that that allows the loading of C based modules directly from source code
[3], as well as making an easy to use API for compiling C code.

  On the good side, TCC compliles *fast* [4].  On the down side, the code it
produces is *not fast*.  It's a trade off.  And it's fun to play with.

  -spc

[1] http://repo.or.cz/w/tinycc.git

[2] https://github.com/spc476/lua-conmanorg/blob/master/src/tcc.c

[3] https://github.com/spc476/lua-conmanorg/blob/master/lua/cc.lua

[4] There was an older version that could boot the Linux kernel, from
        source code, in under 10 seconds.