[linux-audio-user] Re: linux-audio-user Digest, Vol 5,
Issue 27 (Paul Winkler)
lt at westnet.com
Sat Feb 14 20:44:13 EST 2004
On Saturday 14 February 2004 04:55, stefan kersten wrote:
> 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
Sure, I agree, in your application, it's better not to use a conventional GC.
I was just saying, that in _some_ applications, it's not a problem at all. I
was just trying to remind people not to automatically reject the approach of
deferred GC, when the running time of the application is time-limited.
(And of course I wasn't talking about PDA's here. Was I? I certainly apologize
if I gave you the impression that I advocate using a garbage-collecting
language for a flash-based system and/or PDA. I'm quite curious where you
got this idea(?))
> > > 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
haha. It all depends. I could say that it's like trying to clean the garbage
out of your car while you're driving.
I think the point is, that we probably agree, and we are just talking about
> 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.
Hmm, note to self - look into Supercollider...
Actually I have no doubt that you are right, in the sense that I understand
that supercollider is a langauge developed specifically for real-time sound
generation. I really need to look into it.
> > 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 :)
Actually, that was just a general question about the two languages, and not
specifically about comparing the GC between the two; I'm sorry if that wasn't
clear. I had got the impression that Ruby is intended to obsolete Python, in
the sense that there are no major disadvantages to using Ruby vs. Python
(apart from the current popularity of Python, of course).
But, at least on this list, it seems that Ruby has not yet displaced Python as
the scripting language of choice, and I wonder if there is a valid reason for
that, apart from inertia and politics.
More information about the linux-audio-user