Hi again! As Chuck lacks garbage collection, it's probably The language, which needs a manual about garbage collection - I mean, a manual about lack of it. Googling "chuck programming garbage collection" gives these pages: - The Ultimate Top 25 Chuck Norris “The Programmer” Jokes - Chuck Esterbrook: Geek of the Week - Java Programming - Hump Day OT It would be good to know, how much memory things take, how to keep memory from growing full etc. For example - if I close something, will it release memory? Tambet
2010/9/6 Tambet
Hi again!
Hey Tambet!
As Chuck lacks garbage collection,
Well.... There is a partially implemented garbage collector, based on reference counting. Sometimes it works, sometimes it doesn't, sometimes it's count is off and objects disappear. Primitives (like int, float....) should be freed once their scope seizes to exist.
it's probably The language, which needs a manual about garbage collection - I mean, a manual about lack of it.
Maybe, What we need is GC to be finished, then documented. First of all; given a more or less typical modern system CPU cost will be a much bigger bottleneck than memory. Unchuck UGens you no longer need from their connection to the dac and/or blackhole and they won't take cpu any more. Have unused Shreds exit or simply reach the end of their code. If you really want to manually remove objects you no longer need you can do this; null @=> my_object; That should force it to be collected. I'm not sure that also affects UGens but I am sure (as I just tested) that this won't affect currently connected UGens.
Googling "chuck programming garbage collection" gives these pages:
- The Ultimate Top 25 Chuck Norris “The Programmer” Jokes - Chuck Esterbrook: Geek of the Week - Java Programming - Hump Day OT
Yes, this is a rather arcane field. GC is turning out to be harder than anticipated, or so it seems.
It would be good to know, how much memory things take, how to keep memory from growing full etc.
On Unix you can run "top" or some recourse monitor that you may have. On Windows there's the task manager which should show how much memory you are using. In practice I've only once seen this come close to becoming a issue and that involved non-realtime rendering of a ray-tracing reverb which in one (misguided) design used tens of thousands of shreds. If this become a real issue that you actually have we could look at your code and see what optimizations could be made. Don't get me wrong; we do need GC and leaks will be a issue for applications like installations that need to run unattended for a long time using many samples, but for most applications on a system build in the past 5 years you should be fine.
For example - if I close something, will it release memory?
Could you give a example of closing something? I'm not sure what you mean. Yours, Kas.
You have sent seven identical mail to this list - it suffices with one. ChucK does have a GC, a reference count, though not fully implemented. If you check the archive of this list, there has been some discussions about that, about a year ago, I think. It has also been discussed other types of GC. A problem with a collecting GC is that it must work with the perfect timing that ChucK has, which syncs every sample time (at about 44 kHz). On 6 Sep 2010, at 21:52, Tambet wrote:
Hi again!
As Chuck lacks garbage collection, it's probably The language, which needs a manual about garbage collection - I mean, a manual about lack of it.
Googling "chuck programming garbage collection" gives these pages: • The Ultimate Top 25 Chuck Norris “The Programmer” Jokes • Chuck Esterbrook: Geek of the Week • Java Programming - Hump Day OT It would be good to know, how much memory things take, how to keep memory from growing full etc. For example - if I close something, will it release memory?
Tambet
[Redirect from Tambet.]
2010/9/7 Kassen
2010/9/7 Tambet
[Redirect from Tambet.]
I now notice I mis-spelled your name a few times; I blame my dyslexia combined with English lacking a gender-neutral pronoun.
You mostly answered everything ..I meant closing shreds and collecting threads.
Great! Threads we don't need to worry about as ChucK runs in a single (OS) thread. Shreds as objects seem to be collected. If you are having specific issues there shout.
It must be problem with gmail. I have very unstable internet connection - thus it's possible I had to click send seven times; anyway, it usually handles this and sends only one message. There is only one in my sent messages folder.
It happens; unlike Hans I only saw a single mail.
This was, what I wanted to know ..moreover, knowing about the exact cases would be nicest. Because as it's in-use system, such facts should be there in manual (as I already started to worry a lot looking at my simple program, which opens and closes shreds; now I just unchuck).
Indeed, but maintaining and updating the manual takes time and for this case it might be more worthwhile to spend that time fixing the issue instead. Sadly it's not that clear when we will have proper GC.
Google Go, in nearby future, should have very powerful multithreaded GC.
Our case is rather specific. For multi-threading (which we don't yet do) a analysis needs to be made about what parts depend on what others. In ChucK this graph may change rather dramatically as UGens get re-connected. Multi-threading in this context is non-trivial. Yours, Kas.
2010/9/7 Kassen
2010/9/7 Tambet
[Redirect from Tambet.]
I now notice I mis-spelled your name a few times; I blame my dyslexia combined with English lacking a gender-neutral pronoun.
At least you hadn't to tell it out loud :) You mostly answered everything ..I meant closing shreds and collecting
threads.
Great! Threads we don't need to worry about as ChucK runs in a single (OS) thread. Shreds as objects seem to be collected. If you are having specific issues there shout.
Ok, that's nice to know ..I have very imprecise memory monitor, will fix that. Indeed, but maintaining and updating the manual takes time and for this case
it might be more worthwhile to spend that time fixing the issue instead. Sadly it's not that clear when we will have proper GC.
I strongly suggest looking into efforts of Go. Another possibility is to implement protocol for Java garbage collector? - they are pluggable and there are many.
Google Go, in nearby future, should have very powerful multithreaded GC.
Our case is rather specific. For multi-threading (which we don't yet do) a analysis needs to be made about what parts depend on what others. In ChucK this graph may change rather dramatically as UGens get re-connected. Multi-threading in this context is non-trivial.
Multi-core'ing. I would like to do some analysis for that. I am very good analyst as people say. I think I could come out with robust solution if I had enough data about how it exactly works and which are the possibilities - for example, this redirecting. I have painted schemes for garbage collectors ..anyway, I'm stuck enough with time that I could not code it alone :) - but maybe I could create a coherent architecture document as a starting point for review.
Yours, Kas.
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hans;
You have sent seven identical mail to this list - it suffices with one.
Personally I didn't think those mails were the same. They do all touch on -perceived- shortcomings of ChucK. This, I feel, is fair; it's unfinished and under-documented. My own recommendation to Tambet would be to try to get a feel for things and see how far one can get. ChucK, like any other language, has its own ways of solving issues. It also has shortcomings, issues and many bugs.
ChucK does have a GC, a reference count, though not fully implemented. If you check the archive of this list, there has been some discussions about that, about a year ago, I think.
Indeed, but the current state of GC is only vaguely documented. It's only in the list archives and only because Mike Clemow and -to a lesser degree- me pushed function arguments and array elements to their limits that we were able to infer something about what we have now.
It has also been discussed other types of GC. A problem with a collecting GC is that it must work with the perfect timing that ChucK has, which syncs every sample time (at about 44 kHz).
Indeed. But we don't have to calculate a sample every sample; we only need to calculate a block every block; there is some leeway. What I am wondering about is what is leading Tambert to send these seven (trusting on Hans's counting here) emails. Perhaps Tambert is trying to do something very hard that is running into real bottlenecks. If Tambert could send some code that has issues we could have a look at what could be done to avoid the issues it might run into. Yours, Kas.
On 7 Sep 2010, at 00:20, Kassen wrote:
You have sent seven identical mail to this list - it suffices with one.
Personally I didn't think those mails were the same. They do all touch on -perceived- shortcomings of ChucK. This, I feel, is fair; it's unfinished and under-documented.
Actually they were - out new list participant has some problems with the mail program.
On 7 Sep 2010, at 00:20, Kassen wrote:
It has also been discussed other types of GC. A problem with a collecting GC is that it must work with the perfect timing that ChucK has, which syncs every sample time (at about 44 kHz).
Indeed. But we don't have to calculate a sample every sample; we only need to calculate a block every block; there is some leeway.
What are these blocks? I thought Chuck is running in one thread. It is though true that one could free the marker of the memory synchronously, and let a GC in a separate thread collect inasmuch it gets time for it.
Hans;
Indeed. But we don't have to calculate a sample every sample; we only need to calculate a block every block; there is some leeway.
What are these blocks? I thought Chuck is running in one thread. It is though true that one could free the marker of the memory synchronously, and let a GC in a separate thread collect inasmuch it gets time for it.
These refer to the amount of samples that are send to the soundcard at a time, it's set by "--bufsize". This is universal to addressing soundcards and not related to threading as such. Because of the size of blocks we may have more than a samp to spare (per block) for tasks like GC. Maybe we don't have that time in some cases but of course; at some point we will be asking the cpu for more than it can provided, no matter the way in which we ask. Yours, Kas.
On 7 Sep 2010, at 00:42, Kassen wrote:
Indeed. But we don't have to calculate a sample every sample; we only need to calculate a block every block; there is some leeway.
What are these blocks? I thought Chuck is running in one thread. It is though true that one could free the marker of the memory synchronously, and let a GC in a separate thread collect inasmuch it gets time for it.
These refer to the amount of samples that are send to the soundcard at a time, it's set by "--bufsize". This is universal to addressing soundcards and not related to threading as such. Because of the size of blocks we may have more than a samp to spare (per block) for tasks...
OK.
...like GC. Maybe we don't have that time in some cases but of course; at some point we will be asking the cpu for more than it can provided, no matter the way in which we ask.
GC ought to be wholly independent of the ChucK thread that syncs the music, since it is only about collecting unused memory. Suppose you have a collecting GC that runs nicely in the sense that it does not interrupt ChucK perfect timing. Then it could within that limitation collect whenever it gets some time from the system to do it in its own thread.
On 6 September 2010 23:55, Hans Aberg
GC ought to be wholly independent of the ChucK thread that syncs the music, since it is only about collecting unused memory. Suppose you have a collecting GC that runs nicely in the sense that it does not interrupt ChucK perfect timing. Then it could within that limitation collect whenever it gets some time from the system to do it in its own thread.
Both real-time and multi-threaded GC are still considered *hard* issues in the PL community. In a multi-threaded app, you have to address how to keep the mutator alive and kicking during the GC cycle (since the allocation graph is clearly a shared data structure), and in a real-time app, you have to address the problem of deadlines even though the mutator may cause very uneven GC loads. It does turn out that both problems are loosely related, but it's not at all easy to adress the issues in any given application. ChucK's reference-counted approach is one that is works quite well in real-time systems, but reference-counting has the downside that it can be very buggy if it is implemented manually, and it is quite easy to cause naive reference counting to leak (so you still have to be acutely aware of the object life-cycle). david -- GPG Public key at http://cyber-rush.org/drr/gpg-public-key.txt
On 7 Sep 2010, at 10:43, David Rush wrote:
GC ought to be wholly independent of the ChucK thread that syncs the music, since it is only about collecting unused memory. Suppose you have a collecting GC that runs nicely in the sense that it does not interrupt ChucK perfect timing. Then it could within that limitation collect whenever it gets some time from the system to do it in its own thread.
Both real-time and multi-threaded GC are still considered *hard* issues in the PL community. In a multi-threaded app, you have to address how to keep the mutator alive and kicking during the GC cycle (since the allocation graph is clearly a shared data structure), and in a real-time app, you have to address the problem of deadlines even though the mutator may cause very uneven GC loads.
It does turn out that both problems are loosely related, but it's not at all easy to adress the issues in any given application. ChucK's reference-counted approach is one that is works quite well in real-time systems, but reference-counting has the downside that it can be very buggy if it is implemented manually, and it is quite easy to cause naive reference counting to leak (so you still have to be acutely aware of the object life-cycle).
ChucK, because of its strong timing, runs in a single thread. So the question is if one might put something in another thread. A concurrent GC would qualify, at least from the theoretical point of view.
participants (4)
-
David Rush -
Hans Aberg -
Kassen -
Tambet