[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Question about LuaJIT's future FFI/Struct Extension
- From: Leo Razoumov <slonik.az@...>
- Date: Wed, 17 Mar 2010 18:46:11 -0400
On 2010-03-17, Mike Pall <email@example.com> wrote:
> But let's turn that around: what would you (not just you, Duncan)
> like to see in such an API? What would you like to do with it?
> What might help to make it simpler and easier to maintain?
> Real-life examples are preferred of course.
Real time examples at hand: numerical computations and simulations.
Typically, non-trivial numeric algorithms are hard to get right and,
therefore, multiple sophisticated numerical libraries have been
developed over the years that solve certain parts of your problem:
BLAS/LAPACK for linear algebra, GSL or netlib for many other things,
ROOT for everything, etc.
Very often a task of writing a complete numeric program is a task of
gluing those libraries together within a certain context and
scientific logic. And, IMHO, LuaJIT, for one thing, is a very good
glue for that. And for numeric applicaitons good performance is
paramount. I feel real pain when calling from LuaJIT simple
lightweight C++ complex number functions, for it uses more CPU cycles
operating on Lua stack than calling the function body itself ( +-*/ of
two complex numbers come to mind first). And there are many other
examples like that.
Another problem is memory management. In order to harmonize Lua GC
controlled userdata objects with C++ way of memory management I am
currently binding to reference counted wrapper objects. It works fine
but causes some moderate performance degradation due to extra pointer
references and need to maintain ref counts.
C++/Lua inheritance harmonization is yet another story altogether.
Just my two cents.