2.6, 3.0, and truly independent intepreters

[Patrick Stinson]

As a side note to the performance question, we are executing python
code in an audio thread that is used in all of the top-end music
production environments. We have found the language to perform
extremely well when executed at control-rate frequency, meaning we
aren't doing DSP computations, just responding to less-frequent events
like user input and MIDI messages.

So we are sitting this music platform with unimaginable possibilities
in the music world (of which python does not play a role), but those
little CPU spikes caused by the GIL at low latencies won't let us have
it. AFAIK, there is no music scripting language out there that would
come close, and yet we are sooooo close! This is a big deal.

On Fri, Oct 24, 2008 at 7:42 AM, Andy O'Meara <andy55 at gmail.com> wrote:
>
> Glenn, great post and points!
>
>>
>> Andy seems to want an implementation of independent Python processes
>> implemented as threads within a single address space, that can be
>> coordinated by an outer application.  This actually corresponds to the
>> model promulgated in the paper as being most likely to succeed.
>
> Yeah, that's the idea--let the highest levels run and coordinate the
> show.
>
>>
>> It does seem simpler and more efficient to simply "copy"
>> data from one memory location to another, rather than send it in a
>> message, especially if the data are large.
>
> That's the rub...  In our case, we're doing image and video
> manipulation--stuff not good to be messaging from address space to
> address space.  The same argument holds for numerical processing with
> large data sets.  The workers handing back huge data sets via
> messaging isn't very attractive.
>
>> One thing Andy hasn't yet explained (or I missed) is why any of his
>> application is coded in a language other than Python.
>
> Our software runs in real time (so performance is paramount),
> interacts with other static libraries, depends on worker threads to
> perform real-time image manipulation, and leverages Windows and Mac OS
> API concepts and features.  Python's performance hits have generally
> been a huge challenge with our animators because they often have to go
> back and massage their python code to improve execution performance.
> So, in short, there are many reasons why we use python as a part
> rather than a whole.
>
> The other area of pain that I mentioned in one of my other posts is
> that what we ship, above all, can't be flaky.  The lack of module
> cleanup (intended to be addressed by PEP 3121), using a duplicate copy
> of the python dynamic lib, and namespace black magic to achieve
> independent interpreters are all examples that have made using python
> for us much more challenging and time-consuming then we ever
> anticipated.
>
> Again, if it turns out nothing can be done about our needs (which
> appears to be more and more like the case), I think it's important for
> everyone here to consider the points raised here in the last week.
> Moreover, realize that the python dev community really stands to gain
> from making python usable as a tool (rather than a monolith).  This
> fact alone has caused lua to *rapidly* rise in popularity with
> software companies looking to embed a powerful, lightweight
> interpreter in their software.
>
> As a python language fan an enthusiast, don't let lua win!  (I say
> this endearingly of course--I have the utmost respect for both
> communities and I only want to see CPython be an attractive pick when
> a company is looking to embed a language that won't intrude upon their
> app's design).
>
>
> Andy
> --
> http://mail.python.org/mailman/listinfo/python-list
>