Hi Florian,
On 15.11.2012 13:18, Florian Weimer wrote:
On 11/15/2012 01:49 AM, Alek Paunov wrote:
So, to me it seems natural joining all above together to start thinking
for replacing the classic python C bindings with thin textual or
bytecode(*) LuaJIT/FFI shims in benefit of things with great set of
dependencies like Anaconda (thanks to lupa, Lua objects behaves like
Python ones in Python). The result will be order of magnitude easier for
maintenance (towards the APIs evolution) and faster code.
LuaJIT is currently not available for our secondary architectures, so
this would need fixing first. ("not available" meaning exactly that,
there is no fallback to a slow C interpreter mode or something like that.)
Oh, I completely forgot the secondary architectures (besides ARM).
Florian, you follow LuaJIT - what other architectures (except the
clearly missing s390) should be covered ?.
It's also not clear how significant the actual memory savings will be
because some of the Lua OO frameworks have quite a bit of overhead. And
the eventually arriving abrt plugin will bring some weight with it, too.
This is nothing against Lua or LuaJIT. I just don't think that
switching programming languages will magically reduce resource
consumption. This has to be an explicit design goal, or else it is not
likely to happen. I'm sure it's possible to write resource-conserving
Python code, too. It's just the baseline overhead from the run-time
system which is unavoidable, but that's fairly small for Python
(apparently less than 2 MB of unshared RSS per process).
Apparently, my pseudo-English is not enough for a normal communication :-(.
I am commenting on the possibility for deploying LuaJIT FFI as a partial
replacement (problematic + future) of the hand written or SWIG Python
bindings in the first place, not switching the system language from
Python to Lua. In a system tool/daemon written in Python:
* Python loads libluajit.so (import lupa; from lupa import LuaRuntime;
...)
* The C libraries (the targets of the binding) are described as LuaJIT
FFI style bindings in simplified C [my primary point for that is
correctness (avoiding the memory leaks and reference counting problems)
and lowering the burden of the APIs evolution maintenance, not lowering
the general memory footprint]
* The current OO style Python wrappers (the higher level part of the
classical C bindings) are implemented with the Lua metamethods over
plain C objects (without any Lua OO frameworks)
* Python calls the LuaJIT C lib object wrappers (as close as possible
to the Python APIs exposed by the current bindings on top of the Python
C API).
Kind Regards,
Alek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
