Re: BIG request, someone can port luajit ffi module to lua?

[Javier Guerra Giraldez <javier@...>]

On Mon, Feb 21, 2011 at 9:57 PM, Matthew Wild <mwild1@gmail.com> wrote:
> On 22 February 2011 02:14, Miles Bader <miles@gnu.org> wrote:
>> Javier Guerra Giraldez <javier@guerrag.com> writes:
>>>> I hope my lua code can be run both luajit and lua. But ffi is
>>>> most attraction feature, can who do some work to port luajit ffi to lua as a
>>>> extend module.
>>>
>>> far easier is to write two versions of your code: one with JIT+FFI,
>>> one as a traditional Lua/C binding.
>>
>> Writing two version of one's bindings is really annoying though,
>> especially for large interfaces.
>>
>
> Indeed it's annoying. Which is why I suspect many won't bother...


In my experience, writing a C binding is quick and painless, but only
after you've understood the desired usecase of the target library
_and_ settled down on a comfortable enough Lua API.

LuaJIT's FFI makes it far easier to experiment on the Lua side without
having to whip too much C for each test.  that in itself is a huge
contribution, IMHO.  now, on top of it we get that amazing
speedups.... no wonder we're all still shocked :-)

personally, i think there are two cases:

A) existing bindings that might want to add an FFI optimization.
that's the case of ZeroMQ, and it shows that it can be done. and in
most cases it should be transparent, presenting the same Lua API in
any cases.  most of the design is already done, so it's easy for the
original developer to add FFI.

B) new bindings: here's the splitting danger, FFI is easier to use and
gets you faster results, so why bother with the C binding? but as i
see it, once you have the Lua API nailed, adding the C binding is less
than a day of work in most cases.

About using TCC to emulate FFI: yes, it might be doable, and in fact i
thought about it when Mike first explained what kind of style he was
aiming with FFI.  As some might remember; I wrote the original tcc_lua
binding, but was quickly disappointed because of some intrinsic
limitations of TCC.  specifically:

1.- the C context follows a 'compile / link / use' cycle that can't be repeated.

2.- because of the use of global variables, you can't have more than
one C context, nor create a second one after the first one is in 'use'
phase.

3.- there's no port of TCC for AMD64

4.- while an amazing feat, TCC evolved from an obfuscation contest
winner; the code is not what most of mortals call readable.


because of 1 and 2, ttc_lua can't be used to create a long-running Lua
application scriptable in C (my original goal).  think like "embedding
small C scripts in a bigger Lua application".  neat, eh?   sorry,
doesn't work.

because of 3, it's not usable in serious platforms.  (is there any
attempts to solve it?  hope so, but haven't seen them)


Still, for bindings it seems that 1 and 2 aren't so limiting, given
that a binding is defined at startup time and you don't want to
dynamically modify it afterwards......  food for thought certainly;
but i still believe that writing a C binding is waaay easier after you
have the FFI one running.

-- 
Javier