Hi Michael and All, Sorry to chiming in late, I had wanted to respond earlier about the parallel stuff but was a bit busy. >From my earlier work, I don't think that the compiler will be able to analyze all of the dependencies. In the same way we all do multi-threaded programming with mutexes, semaphores, barriers, etc., because the compiler can not do the work for us in languages like C/C++/Java/etc., we have to manually guard access to global data. I believe the same thing would be required for coding Csound instruments. If you want to take advantage of multiprocessor csound and your instruments are going to be touching a global resource, then you should use a mutex opcode to guard it yourself. This was the rationale at least as to why I put in the mutexops opcode library. Also, I don't think that analyzing the graph is possible. There's known global resources that we might be able to protect automatically (access to global variables, ftables, zak, host signal buss, etc.). There are things like FLTK and Fluidsynth which have some global data like fluid engines and windows that could be protected. However, these are known resources. If anyone creates a new opcode library, there is no way for the compiler to know that the opcodes in that library access global resources or require special handling. We could add meta-data to all opcodes, which might help, or we can say all opcodes are responsible for guarding against concurrency themselves, but the fineness of granularity of locking then may not yield such a benefit as manually coding using mutexes one's self in Csound coding as a user. Regarding the partitioning of work, I thought about this a long while and Michael touched on it, Csound currently has a set processing order. That order is, process all instances of an instrument, then move to all instances of the next instrument, and so on. Users code their orchestras relying on this natural processing order. For example, 3 notes for instr 1 may all mix their signal to a global var, then 1 instance of instr 2 may take the mixed signal and apply reverb. Trying to automatically analyze the graph and try to partition in a way that would allow a work thread to do more than one instrument at a time would be very tricky. In the example above, instr 1 does a read and write into a global var to mix the signal, and instr 3 does just a read. How to know if it is alright for instr 3 to read when another thread finishes processing their instr 1? It might be the case that another instr 1 has not yet written to the global sig. We might come up with a hard rule saying, okay, if an instrument earlier writes and one later reads, partition at instrument level, but I would say this kind of partitioning problem is going to be tricky to do. What I see as the most likely way to achieve some benefit is to have worker threads partition the instances of an instrument. I would say this is the best place to start and what we should aim for first as it is the easiest to achieve and still preserves all processing order of single-threaded csound. This is the approach taken in the work I committed and is in CVS, and even then it reveals that there is a lot of work required to handle concurrency in even this relatively simple approach. I would say if we do this first, we would get to focus on all of the essential changes required for concurrency (in other words, this work is foundation work we need to do no matter what the eventual strategy is used). Thanks, steven On Thu, Apr 24, 2008 at 5:44 AM, Michael Gogins wrote: > outs can have a list of buffers to be combined at the end of the kperiod. That is to say, each thread has its own spout. When all threads have finished their kperiod the thread spouts are summed to the global spout which actually goes to the soundfile or audio output. > > I recommend that you look at Intel Threading Building Blocks, parallel for and parallel reduce. This is parallel reduce. > > By the way, I think parallel rendering is the most important project on the Csound agenda at this time. Starting right now -- since quad core is a reality -- a software sound synthesis system must be parallel. If Csound is not parallel and SuperCollider or something is, everybody will just switch. And similarly, if Csound is parallel and others are not, everybody will just switch to Csound. > > > Regards, > Mike > > -----Original Message----- > >From: jpff > > >Sent: Apr 24, 2008 6:30 AM > >To: Michael Gogins , Developer discussions > >Cc: csound-devel@lists.sourceforge.net > >Subject: Re: [Cs-dev] Profiling csound -- revised again > > > > > >Regarding parallel Csound, I was designing a system on the bike last > >week. If/when I get a free gap I wanted to try the following attempt > >at multi-core. > > > >If an instrument does not access globals or zak then we can have a > >small group of worker threads that run instruments in parallel. This > >could be policed with a small change to the parser. However there is > >a flaw -- out is in effect a global access. So as an experiment > >replace outs with a version that checks a semaphore, ignore the > >zak/globals for now, and see if there is any performance gain. This > >seems a simple investment. > > > >I am convinced that the solution lies in compiler-time analysis. If > >one breaks it all down to dataflow level the overheads dominate -- > >that seems to be the lesson of Midas. > > > >I will read Mike's message more carefully soon -- drowning in e-mail > >(mainly from students who have to hand in their dissertation next > >Monday) > > > >==John ffitch > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > Csound-devel mailing list > Csound-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/csound-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone _______________________________________________ Csound-devel mailing list Csound-devel@lists.sourceforge.net