[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT FFI/C++ binding, best approach?
- From: Mike Pall <mikelu-1107@...>
- Date: Mon, 18 Jul 2011 12:40:42 +0200
Steven Berry wrote:
> I have non-virtual methods working fine but still need to get virtual
> methods working.
Most of the C++ compilers use a virtual table. This is pointed to
by a hidden field at the beginning of the struct/class. The layout
of the virtual table usually follows this convention:
> It also allows me to use ffi on the ipad but without the jit using ffi is
> about 8-10 times slower than the older binding style.
> Is this the expected performance gap? Would you recommend using non-ffi
> bindings when jit is disabled?
Yes, the FFI has been designed with a JIT compiler in mind. It's
rather slow without the JIT compiler. So you can still use it for
convenience (ad-hoc calling any C function), but probably not if
you require performance (calling a C function many, many times).
BTW: Unlike iOS, the JIT compiler works fine on Android. ;-)
> Thanks. That nearly halved the size of the lua file. I also realised that
> Test1 = function() return Test1_mt(C.Test1_new()) end
> should have just been
> Test1 = function() return C.Test1_new() end
Umm ... Test1 = C.Test1_new
> > [Whenever I get around to parse a very restricted subset of C++, most of
> > that will be superfluous. But don't hold your breath.]
> For me personally, if FFI could handle basic classes as "interfaces" and
> simple inheritance I would be happy :-)
The problem is that everyone would like to have a different subset
of C++ supported. This will add up. Also, even indirect use of
complex libraries (e.g. inheriting from a Boost class) kills that
I'm not so sure whether it's possible to define a useful subset of
C++ which would still make a majority of users happy. That doesn't
mean I won't try (I already have a potential sponsor for this),
but I really don't want to add an ineffectual solution.