[chuck-users] GC vs real-time (was Getting Started with ChucK)

[Hans Aberg]

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