Re: From Lua to Python?

[Russell Haley <russ.haley@...>]

On Tue, Feb 6, 2018 at 11:55 AM, Russell Haley <russ.haley@gmail.com> wrote:
> On Tue, Feb 6, 2018 at 7:06 AM, Tom Cook <tom.k.cook@gmail.com> wrote:
>> On Mon, 5 Feb 2018 at 16:56 Coda Highland <chighland@gmail.com> wrote:
>>>
>>> Lua's GC stops the world. All garbage collectors do. Lua's is just
>>> reasonably well-behaved and tries to avoid big sweeps as much as
>>> possible by doing smaller collections more often. It's also easier to
>>> write Lua code that generates less garbage. And if you're doing
>>> one-state-per-thread (the recommended way of doing it) then you're
>>> only blocking one thread instead of the world.
>>>
>>
>> I am no expert on the ins-and-outs of garbage collection, but I understand
>> this is not the case - see http://lua-users.org/wiki/LuaInRealTimePrograms.
>>
>>> > Perhaps the biggest difference is that integrating C++ code with Python
>>> > is
>>> > light years easier than integrating C++ code with Lua.  Boost::Python
>>> > makes
>>> > it all so, so easy, while trying to keep a ten-deep stack straight in
>>> > your
>>> > head on the Lua side was an endless source of defects.  Again, there
>>> > might
>>> > be something out there that does all this for you in Lua too, but we
>>> > didn't
>>> > know about it or find it.
>>>
>>> You just didn't look far enough. There are several Lua frameworks for
>>> C++ integration. lua-primer and luabind come up as the first two hits
>>> in a Google search.
>>
>>
>> Well, so we didn't look far enough.  On a quick inspection, neither of those
>> look nearly as good as boost::Python, but that might be an aesthetic thing.
>>
>>>
>>>
>>> > Regarding some of the accusations of "bloat" against the Python
>>> > libraries
>>> > above - of course this is perfectly true.  But I'm not sure why it
>>> > matters.
>>> > That "bloat" doesn't cost you at runtime unless you use it - when it
>>> > becomes
>>> > useful library, not bloat.  So unless you're trying to install this on
>>> > decades-old computer where disk space is a serious issue, what is the
>>> > cost
>>> > of that bloat?
>>>
>>> Embedded systems are modern but have serious disk space constraints.
>>> Also the presence of those libraries as "standard" means the ecosystem
>>> depends on them, so you never know when one of your dependencies is
>>> going to pull those in and start using up RAM as well. It's not a
>>> horrible cost, but it's something to be aware of, and Python is a
>>> fairly slow language to begin with. It's still a fantastic tool, but
>>> if you're comparing it to Lua, then that's one of the things to look
>>> at.
>>>
>> I work almost exclusively in modern embedded systems.  It's been a long time
>> since I've come across one where either volatile or non-volatile storage is
>> a serious constraint.  Yes, we're careful about how we use it in
>> deterministic code, but the actual amount available is almost never a
>> constraint.  There is still a lot of kit out there that does have these
>> constraints, so maybe I'm lucky that I haven't been required to work with
>> old hardware for a long time.
>
> There are amateur type, low-level hardware kits that exclusively use
> Python as the development interface. It's all very do-able but... IMHO
> anything using smaller than an Armv5 system with Python starts to
> become problematic. From what I understand the instruction sets are
> *very* limited and that causes problems for languages like Python. For
> reference, Cortex A8/Armv6 is about the smallest most companies use
> now unless it's dedicated/custom hardware (done lots of peering into
> competitors and custom display systems).

Also for reference, a smallish System On A Module (SOM) I possess has
512 MB raw NAND, 1gb eMMC, and 512MB ram. It's a Freescale iMX53,
which is a single core Cortex A8. The board is called a Digi CCWMX53
(I think...).

> I have limited knowledge of Python, but I think like most languages,
> it's probably fast enough until someone decides to create a library to
> help the developer out. Then, overhead starts to creep into the
> equation. From what I've seen with Python, it's all about the helper
> libraries.
>
> What validated my decision to use Lua was that OpenWRT runs on routers
> with *very* small memory modules (volatile and non-volatile). From
> what I understand it uses Lua exclusively for interfacing with the OS
> and other subsystems. I don't think I'd try running a router with
> Python. :)
>
> Russ