12 Feb
2004
12 Feb
'04
4:28 a.m.
Paul Winkler
On Wed, Feb 11, 2004 at 05:27:14AM -0800, Bill Schottstaedt wrote:
Yes, but python have a reference-count garbage collector, so
the problem shouldn't matter for python.
--
I don't think this is a problem; you can
usually turn off
the GC during time-critical code, and in most cases, such code
is in C anyway (handled via a foreign function interface), and
at least in normal use, you're in control at that level.
I don't know about other garbage-collected languages, but
there is no way to temporarily disable GC in Python,
nor any way to force it to run at a particular time.
12 Feb
12 Feb
7:42 a.m.
On Thu, Feb 12, 2004 at 09:24:28AM +0100, Kjetil Svalastog Matheussen wrote:
note that reference counting behavior doesn't differ that
much from a sweeping gc: as soon as a count to a large
object tree drops to zero the whole tree will be freed
instantly, causing an indeterminate delay in execution,
unless you defer free operations until there is time to
perform them. additionally, AFAIK python uses malloc/free
for memory management, which are inherently non-realtime.
i'm not sure if turning off gc is a real solution for (long
running) musical applications. why'd you have a gc in the
first place? when do you turn it back on? what about
applications that constantly create many small objects?
realtime gc algorithms OTOH have been around for some time
(baker's initial treadmill paper is from '78) and can even
deliver hard realtime 'performance'. nothing's for free,
though: they usually impose more restrictions on a language
runtime, e.g. WRT foreign language interfaces, and probably
suffer from internal fragmentation more than other
(compacting) algorithms.
<sk>
I don't
know about other garbage-collected languages, but
there is no way to temporarily disable GC in Python,
nor any way to force it to run at a particular time.
Yes, but python have a reference-count garbage collector, so
the problem shouldn't matter for python. 
13 Feb
13 Feb
11:16 p.m.
(I'll assume we're talking about Python the scripting language, and not the
original Python - the CMUCL compiler)
On Thursday 12 February 2004 06:38, stefan kersten 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.
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?
Larry Troxler
14 Feb
14 Feb
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>
9:56 p.m.
On Saturday 14 February 2004 04:55, stefan kersten wrote:
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.
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
different application.
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.
Larry Troxler
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.
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(?))
Larry Troxler
when do you turn it back on?
Simple. You do a full GC whenever you stop a real-time
run. 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 :)
<sk>
7934
days inactive
7936
days old
linux-audio-user@lists.linuxaudio.org
4 comments
3 participants
participants (3)
-
Kjetil Svalastog Matheussen -
Larry Troxler -
stefan kersten