On 23 Jul 2009, at 21:10, Tom Duff wrote:
The thread in comp.compilers on reference counting mentioned that the Java collector, when buffered grew beyond 50 MB or so, could choke and hang for tens seconds, even on the latest Macs.
I'm not sure why this is relevant or responsive. All this demonstrates is that if you use inappropriate methods, you may very well get inappropriate results.
It means it it is hard to use appropriate methods on modern systems.
Even if the GC works fine on a machine without virtual memory, it could choke in a virtual memory environment, if tracing takes place on swapped out memory. The whole system can choke. The before mentioned thread also gave some references, but none that actually solves the problems.
Again, I'm not sure why this is relevant. Virtual memory is a relic of a bygone era. I don't recall having a paging-related performance problem in music software in the last 15 years. Even my laptop has 8GB of primary storage. Nothing ever gets paged out.
What do you mean by this? All computers use virtual memory these days. They page in and out all the time, and you do not have control over it. You can decrease the effect by putting in more RAM, but that is no guarantee.
And Chuck is in fact resource demanding because of its exact timing model. Simple IO in fact causes delays, enough to make real time medoic playing difficult (though I tried it in a not so fast computer).
What does this have to do with garbage collection?
It is hard even to reserve small time-gaps for stdout.
The last time I looked, a couple of months ago, Chuck's garbage collector was a stub, and even the stub wasn't called from anywhere. It doesn't have one!
The context was to find one suitable for Chuck.
Have you used Supercollider? Does it have the delay problems you're worried about? Are they attributable to the garbage collector?
You tell me. In Chuck, if I play a fast rachenitsa on the keyboard, I notice that the ornaments become delayed if there is some IO to console going on. Does that happen in SuperCollider? If you have some really big programs in SC, you the GC must be used much, does that affect the timing? HOw do check that the GC is in use on SC? The thing is that a GC can be made arbitrarily effective by increasing its buffer. If it is infinite, just allocate memory and never deallocate. Memory allocation can be made in perhaps just one or a few cycles. This is the case of a two-space copying GC. But when GC time comes it becomes slow. If you increase the buffer, it means that it takes longer time before GC, but there is bigger problem ahead. Your comments suggest that you just increase RAM to avoid GC time and virtual memory paging. But that is no solution of the GC problem - just avoiding it.
I don't know what you mean by "Simple IO" and in fact I don't believe that delay inhibits real time melodic playing. Tracker action pipe organs typically have key-to-sound delays of 250 milliseconds or more. For centuries they have been the primary instruments of many of the foremost improvisers in western music.
Unpredictable timing (delay jitter) is undoubtedly a musical problem, but Wilson's incremental real-time garbage collector, as used in Supercollider, is designed specifically to eliminate that.
The problem is that it is unpredictable. Mostly noticeable in rapid movements. In Chuck, it happens even if there is no CPU overload. Seems tied to its single thread implementation. Hans