Hi All, I don' t know if multithreading per-ugen is actually a good way to go, but it's honestly an "I don't know". My concern is that of granularity of locking, that if we have to do lock/unlock on each ugen, then we will be increasing the amount of time required to divide up the work per thread, plus potentially adding more time for waiting for each thread to return. I think the ideal strategy would be to divide the work up with the biggest amount of work possible per thread. In this case, at the instrument level seems the way to go, with code within unit generators potentially doing their own multi-threaded work (i.e. FFT). However, if by per-ugen I read it wrong and the work is scanned and broken up into chains of ugens that can be divided, i.e. analyze and break up an instrument into two chains of work per instance, then have the threads operate on the chains, then that might be optimal. But then again, this requires a great deal of meta-information on what resources an opcode touches and if they are global or not. BTW: Going back to work I and Michael have been doing, as well as thinking about John ffitch's concerns, I'm seeing we have two main tasks at the moment: 1) Make Csound operate in a multithread-safe manner. Some of the issues here have already been discussed like the use of CUREVT for goto's which is not threadsafe. There are a number of fields in the CSOUND struct which are essentially global that will require some rework to get rid of. 2) Strategy for work division and operation: Do we operate at instrument level? Do we attempt to automatically provide mutex locking/unlocking? Do we even use mutexes? The 2nd issue is debatable but I think for must of us theoretical too, and that we may all have to just experiment with implementations. Ideally, we would do so in a way where the experiments build up on each other. While writing this email, I am thinking to aid in John's proposals for automatic analysis for locking/unlocking so that user's won't have to do it, we might want to add an extra field to OENTRY for a callback function that will return metadata about the opcode. The metadata could be a series of bit flags, such as: #define CSOUND_THREAD_UNSAFE 0x00000001 int getOpcodeMetaData() { return CSOUND_THREAD_UNSAFE; } The code to partition work could then check if an opcode is thread unsafe and insert instances of the mutex_lock and mutex_unlock opcode. However, this again brings up the problem of granularity of locking. If a block of code really requires locking over the whole block, like: mutex_lock 0 if (gi_my_special_table == 0) then gi_my_special_table ftgen 0, 65537, 10, 1 endif mutex_unlock 0 I'm not sure how we would be able to do automatic analysis. We could do some check on global variables during parse time, but after parse time, we have no knowledge if an opcode is using a global variable or a normal variable. At this time, I'm much more concerned about making Csound multi-thread safe than the partitioning/work strategy, as none of the latter work will work without the former, so will be working towards that goal for now. As for strategy, I'm still thinking that at this time, the use of explicit code for mutex locks is unavoidable, and while I would love to see automatic analysis and optimal work division, I think we'll have to do a lot more design work to account for the many situations that will be concerns for multithreading. Thanks! steven On Fri, Jul 4, 2008 at 8:15 AM, victor wrote: > There's a panel on the topic at the next ICMC, so we'll learn more about it. > I like the idea of nultithreading of ugen calls; would it not be something > to consider? > ----- Original Message ----- > From: "Michael Gogins" > To: "Csound Developers" > Sent: Friday, July 04, 2008 4:03 PM > Subject: Re: [Cs-dev] [CM] thread progress report > > >> What yet another software sound synthesis system is up to these days >> (below).... >> >> It's obvious that all serious SWSS, within a year or so, will have fairly >> robust multi-core scalability. >> >> Those I know about so far: >> >> Max/MSP multi-threading in poly~ in stable production >> Csound multi-threading of instrument instances experimental >> CLM multi-threading of unit generator calls? experimental >> >> Does anyone know the status of others? SuperCollider? Nyquist? Pure Data? >> >> I do not know as much about commercial digital audio workstations, but I >> know that they use threads internally, so it makes sense that they either >> already are, or soon will be, multi-threading plugin instances and track >> processing. >> >> Cubase has been multi-threaded and multi-core for a long time, but some >> plugins have problems running multi-core. >> >> Regards, >> Mike >> >> -----Original Message----- >>>From: Bill Schottstaedt >>>Sent: Jul 4, 2008 10:20 AM >>>To: cmdist@ccrma.Stanford.EDU >>>Subject: [CM] thread progress report >>> >>>Some first impressions of Snd/CLM and threads: on a machine with >>>2 quad-core 3.0 Ghz 86-64 processors (8 "cores"), I can currently >>>get with-threaded-sound to run about 4 to 6 times faster than >>>with-sound, and multichannel edits (filter-channel) run 6 to 8 >>>times faster. I'm still chasing race conditions and so on, but this >>>looks promising. Also, if you have 8 GBytes or more RAM, you >>>can now use that 2^32 element table-lookup you've always >>>wanted -- I think all vct, sound-data, and clm table sizes can >>>be off_t's. Use mus-fft for an fft in that size range (and take >>>a vacation while it computes). >>> >>> >>>_______________________________________________ >>>Cmdist mailing list >>>Cmdist@ccrma.stanford.edu >>>http://ccrma-mail.stanford.edu/mailman/listinfo/cmdist >> >> >> >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Csound-devel mailing list >> Csound-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/csound-devel > > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net