[CM] S7s GC

[Iain Duncan]

Thanks Bill, that looks very encouraging. I have to context switch over to
earning a living for a couple of days, but I will dig into this later this
week. I think it would be helpful to be able to turn the GC on with control
of whether it is instantly triggered, from both C and Scheme, but it sounds
like it should not be a problem to get it to work fine for note/control
level realtime. (aka "very soft realtime"? haha). Most people running a
real time DAW with softsynths are going to be expecting to run with an
audio latency of 5ms or more anyway, so I think this should be possible.
(Phew!)

That makes sense about the threading. I need to figure out exactly how Max
handles it's switches too. There may be some kind of protection there that
I don't know about (not the most documented part of Max...)

I sure appreciate the help fellows!
iain

On Mon, Nov 23, 2020 at 7:25 AM <bil at ccrma.stanford.edu> wrote:

> in C:
>
> s7_gc_on(sc, false); /* blocks the GC from running, but the heap will
> grow if necessary */
> s7_gc_on(sc, true).  /* allow the GC to run, does not trigger the GC */
>
> in Scheme:
> (gc #f) ; same as s7_gc_on(sc, false)
> (gc #t) ; turns GC on and calls the GC
>
> I could change (gc #t) to simply re-allow GC's I suppose.
>
> On the times: here I am running s7test (which creates lots of objects)
> with
> (set! (*s7* 'gc-stats) #t)
>
> /home/bil/motif-snd/ repl s7test.scm
> load s7test.scm
> gc freed 111174/128000 (free: 126037), time: 0.000683
> gc freed 117417/128000 (free: 125595), time: 0.000442
> gc freed 111427/128000 (free: 111491), time: 0.000632
> gc freed 109546/128000 (free: 111432), time: 0.000835
> gc freed 103932/128000 (free: 111446), time: 0.000549
> gc freed 123825/128000 (free: 125522), time: 0.000489
> gc freed 95883/128000 (free: 123736), time: 0.000485
> gc freed 3015/128000 (free: 123799), time: 0.000366
> gc freed 121331/128000 (free: 121395), time: 0.000806
> gc freed 123449/128000 (free: 123513), time: 0.000741
> gc freed 107711/128000 (free: 123489), time: 0.000832
> gc freed 111976/128000 (free: 123443), time: 0.000642
> gc freed 109104/128000 (free: 115881), time: 0.000687
> gc freed 101924/128000 (free: 115603), time: 0.000579
> gc freed 98488/128000 (free: 114473), time: 0.000575
> ...
>
> So the interruption is normally less than a millisecond (this is using
> the default heap-size, but I don't think that matters much).  The mark
> process is almost insignificant in the overall computation, so don't
> worry
> about object types or layouts. The only case I've seen where it matters
> are GC benchmarks based on millions of huge lists (mark_pair traverses
> each list, which can become tedious).
>
> It's possible you haven't noticed the GC because it's not being
> called much -- s7 goes to great lengths to avoid creating
> objects itself:
>
> (define (f)
>    (do ((i 0 (+ i 1))
>         (sum 0))
>        ((= i 1000) sum)
>      (set! sum (+ sum i))))
>
> (gc)
> (set! (*s7* 'gc-stats) 7)
> (display (f)) (newline)
> (gc)
> ;; gc freed 102/128000 (free: 127828), time: 0.000084
>
> Set gc-stats and run your code -- maybe you don't need to do anything.
>
> I think if you have 2 threads calling into the same s7 interpreter, you
> do need
> to be sure they don't interrupt each other.  If you try to call
> s7_eval_c_string
> or something while the GC is being run from some other thread, you'll be
> unhappy.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20201123/05557e5d/attachment-0001.html>