[linux-audio-user] Re: linux-audio-user Digest, Vol 5,
Issue 27 (Paul Winkler)
steve at k-hornz.de
Sat Feb 14 04:55:04 EST 2004
On Fri, Feb 13, 2004 at 10:03:59PM -0500, Larry Troxler wrote:
> > i'm not sure if turning off gc is a real solution for (long
> > running) musical applications.
> It could be a perfectly fine solution, depending on the application, if the
> maximum expected run-time is bounded. Before you say this is an unreliable
> hack, consider that in principle, this is no different than recording into a
> conventional MIDI sequencer, where the sequence data is stored in RAM. Yes,
> eventually, if you record long enough, you will run out of room.
ok, i was being a bit unspecific.
consider an installation running 12 hours a day. the program
creates objects (events, synthesis patches, processes)
dynamically and non-deterministically, e.g. based on room
temperature or the number of unemployed people in germany
(which seems to be unbounded).
or imagine a performance involving devices with limited
resources (e.g. PDAs). i wouldn't want the application to
crash _anytime_ because it's running out of memory. it's not
really comparable to a recording situation, where you can
start over when that happens.
so yes, for some applications i'd call it an unreliable
> > when do you turn it back on?
> Simple. You do a full GC whenever you stop a real-time
that's like cleaning your appartment whenever you have
nothing important to do. there's always something to do, so
you have to do the cleaning incrementally and if possible
non-interruptively, or the garbage will spill out of the
> >what about
> > applications that constantly create many small objects?
> What about them? I'm not sure I understand the question.
see above. the whole point about garbage collection is not
having to worry about allocating even small objects
dynamically and automatically getting rid of them as soon as
they're unused, which makes garbage collected languages so
much more suited for high-level abstractions.
i'm not opposed to garbage collection per se, i just think
that there are implementations better suited for realtime
work (like those found in supercollider, rscheme and maybe
squeak) than the reference counting or mark-and-sweep
algorithms used in most scripting languages. supercollider,
as a bonus for object oriented folks, also has constant time
> Incidentally, it's interesting to see that there is not much mention of using
> Ruby instead of Python, in the Linux computer-music world. Presumably Python
> must still have an advantage in some areas?
i don't know if there are big differences in performance
(but since we're talking about garbage collection, ruby has
a mark-and-sweep collector). i, for one, favor ruby for its
cleaner object model, and snd has a ruby but no python
More information about the linux-audio-user