Re: Lua vs Python C bindings

[Dibyendu Majumdar <mobile@...>]

On Sun, 23 Jun 2019 at 18:47, Hugo Musso Gualandi
<hgualandi@inf.puc-rio.br> wrote:
>
> > 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.
>
> These things make it harder to optimize the code around the C function
> call but do not affect how hard it is for the interpreter to actually
> invoke the C function.

Quite a bit hard. Basically if you don't have static typing / function
declarations then performance will degrade significantly.

>
> > In a language
> > where a function has a static identity it would be possible to create
> > specialized bytecodes that efficiently invoke the C function.
>
> The problem is that it is impossible to implement these bytecodes if
> your interpreter is written in standards-compliant C. The C language
> doesn't have a way to apply an arbitrary function (which can be of any
> type) to a dynamically constructed list of arguments (which can be of
> any length). You would need to create an infinite set of bytecodes, one
> for each possible C function type.
>

Agreed that one cannot have an infinite set of bytecodes. I had the
idea of handling common scenarios as a fast path - where arguments are
64-bit quantities (integer or floating point) and passed by register
(4 on win64, 6 on Linux64).
The main issue I found was not the number of bytecodes - the issue was
each argument has to be checked for correct type.

What I was trying to say is that static typing is the key factor in
performance. But it poses interoperability issues with Lua.

Regards