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