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>
