Subject: Re: [linux-audio-dev] News about sequencers (not my own though!)
From: jfm3 (jfm3_AT_acm.org)
Date: pe tammi 21 2000 - 10:45:15 EST
Paul Winkler wrote:
> jfm3 wrote:
> > One can use an incremental collector, which causes all allocations to happen
> > in constant bounded time.
> >
> > For time critical real time sections, one can just lock a larger portion of
> > memory (and other resources) before entering the section, then prohibit
> > garbage collection until the section is complete.
>
> I don't think I'm going to hack python's memory management... that's
> a few too many levels above my head. :)
It does sort of defeat the purpose of re-using someone else's system. :)
> > > Further, speed might be a serious problem.
> > > Even if it could be acceptable to eat 80% of the CPU time, you have to
> > > buffer the results (and output them using some streamlined function,
> > > preferably in native code), to get rid of the jitter that grows with
> > > execution time.
> >
> > In my experience, most modern interpreted language systems don't have this
> > problem.
>
> does your experience include python? what have you done with it?
I almost hacked python into a MIDI system exclusive library thing I have on the
back burner. After writing a couple of large programs in python I decided Guile
was a better bet. Purely personal taste.
I'm not sure what kind of collector Python uses. Let me go look...
Oh. Python uses reference counting. You're home free. Allocation and
deallocation in reference counting allocators happens in constant bounded time.
That means that if your Python program runs fast enough the first time, it'll run
fast enough every time (assuming the OS doesn't time share too many cycles away
from it -- but that's a separate matter).
The Boehm-Demers-Weiser conservative garbage collector (popular among interpreted
language implementations, used by Guile) can be configured to work incrementally,
and multi-threaded versions have been experimented with.
As for whether Python will become slower the longer it runs, I'm not sure why
that claim was made. I suspect whoever made that claim was thinking of the
"locality of reference" problem on paged memory systems with automatic
allocators. If you have enough physical memory to hold the Python process for an
extended period of time, you shouldn't have any problems.
A final thought for this already too long letter. Doing anything "real time" in
Python or any other interpreted language is probably a lose in the long run. As
a counterexample to that claim, Keykit seems to go fast enough, but in my gut
I feel that eventually I'll want something to go really fast and I won't be able
to get the interpreted system to do it quick enough. I also intuit that the
right design for programmatically controlled music systems is one where the
extension language feeds higher level control commands to a real time thread. In
my platonic ideal, the extension language puts things "in order" but the real
time thread puts things "in time".
(jfm3)
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:23:26 EST