Hi Michael, That'd be great! I got sort of stuck looking at the Windows threading API on MSDN and then got distracted, but remembering thinking it had things already to easily implement the barrier code. I have been focusing on blue programming a lot lately and thought the new parser might be nice to give some attention to again, but parallel processing seems like a more value at the moment in looking at. So I will try to join in helping on this when the barrier stuff is done on windows. Thanks and good luck! steven On Sun, Apr 27, 2008 at 9:30 AM, Michael Gogins wrote: > Thanks for the update. I think we should just start doing this. I will first > try to get the barrier code working on Windows. > > Best, > Mike > > ----- Original Message ----- > From: "Steven Yi" > To: "Michael Gogins" > Cc: "Developer discussions" > Sent: Sunday, April 27, 2008 3:37 AM > Subject: Re: [Cs-dev] Profiling csound -- revised again > > > > Hi Michael, > > > > What I had implemented and is currently committed is really just a > > naive start and is only working on Linux and Mac. What happens if you > > enabled --num-threads=x where x > 1, that alternate performance method > > you found is run. It's ugly in that it find the boundaries for note > > instances per instrument and partitions the work for that instrument > > on every k-pass, which is heavy work to do IMO. It uses num-threads > > in a pool and uses two barriers (code came from John for the barrier), > > one to signal all the worker threads to start, the other to wait for > > all of the threads to finish their work. > > > > This works, but when I did this code last year it revealed that while > > Csound might be re-entrant, it still has global level variables in > > use. The one I found most problematic at the time was currevent on > > the CSOUND struct. This member is referenced by opcodes that do jumps > > to labels (goto's, if's, etc.). They use it to get the head of the > > single-y linked list of opcodes and then traverse to search for > > labels. This variable might be used for other things, I'm not sure, > > but this would definitely need to be removed for parallel processing. > > At the time I figured the best way would be to make the opcodes a > > double-y linked list so that an opcode could traverse previous to find > > the head itself and then walk forward to find labels. > > > > Beyond that, to continue where I left off, we'd have to implement > > barrier code on Windows. The work partitioning is awful as mentioned > > above, but it's not incorrect, meaning it could be left as-is and more > > important things could be addressed first like finding all the > > variables like currevent which are really global variables and to redo > > their usage to be thread-safe. This would mean doing things like > > protecting spin and spout, etc. Again, these are all issues that > > would need to be addressed regardless for any parallel solution. > > > > steven > > > > > > > > > > > > On Thu, Apr 24, 2008 at 12:14 PM, Michael Gogins > > wrote: > >> Steven, thanks for your response. I'm only going to touch on part of it. > >> > >> > >> > >> >What I see as the most likely way to achieve some benefit is to have > >> >worker threads partition the instances of an instrument. > >> > >> OK, let's take that as the starting point. > >> > >> > >> >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). > >> > >> Can you outline your general approach? > >> > >> How close is what you have done to working? What more needs to be done? > >> > >> Regards, > >> Mike > >> > >> > >> > >> > > > > > ------------------------------------------------------------------------- > 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