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 <[email protected]> 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. > >
_______________________________________________ Cmdist mailing list [email protected] https://cm-mail.stanford.edu/mailman/listinfo/cmdist
