Re: [linux-audio-user] Re: linux-audio-user Digest, Vol 5, Issue 27 (Paul Winkler)

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-user] Re: linux-audio-user Digest, Vol 5, Issue 27 (Paul Winkler)
From: stefan kersten (steve_AT_k-hornz.de)
Date: Sat Feb 14 2004 - 11:55:04 EET


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
hack.

> > when do you turn it back on?
>
> Simple. You do a full GC whenever you stop a real-time
> run.

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
windows.

> >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
method lookup.

> 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
interface :)

<sk>


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Feb 14 2004 - 11:56:16 EET