14 Feb
2004
14 Feb
'04
6 a.m.
On Fri, Feb 13, 2004 at 10:03:59PM -0500, Larry Troxler wrote:
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.
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.
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.
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. when do you
turn it back on?
Simple. You do a full GC whenever you stop a real-time
run. what about
applications that constantly create many small objects?
What about them? I'm not sure I understand the question. 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>