Re: Lua vs Python C bindings

[Dibyendu Majumdar <mobile@...>]

On Sun, 23 Jun 2019 at 15:48, Hugo Musso Gualandi
<hgualandi@inf.puc-rio.br> wrote:
>
> The LuaJIT FFI interface is an example of this. Inside JIT compiled
> traces it simply inserts a call to the C function inside the generated
> machine instructions. It is as fast as such a call can get. However,
> outside compiled traces the interpreter must implement FFI calls with
> clever non-portable assembly code that knows how to call an arbitrary C
> function with potentially any number and type of parameters. This is
> slower than when the C calls are compiled to machine code, which is the
> case of the traditional Lua-C API and of LuaJIT's FFI inside compiled
> traces. This means that if you are using the LuaJIT FFI you really want
> to be sure that the code surrounding your FFI calls is free of "not yet
> implemented" language features.
>
> A fully-compiled language like Cython, Pallene, or Titan doesn't have
> to worry about interpreting the C calls, which interpreters like
> PUC-Lua, LuaJIT or Ravi have to. Titan already has some experimental
> support for external C calls through a LuaJIT-like interface. Pallene
> doesn't have this yet but it is on our long term plans.
>

I think that the issue is not whether it is compiled or not. Lua
functions are values, so you don't know that they are actually
functions or not, what arguments they take, and what the return type
is. Thus, you don't know that the function being called is a C
function, until you see the value. You cannot assume that the next
time you see the value it will be the same function. In a language
where a function has a static identity it would be possible to create
specialized bytecodes that efficiently invoke the C function.

Regards