Steven, thanks for your thoughts.

Regarding global data, it may be possible to protect such data and use it 
anyway from multiple threads, inside the Csound code, not requiring the user 
to create mutexes using the opcodes.

I know about two approaches: locks (mutexes) and lock-free programming. I'm 
not yet sure which is best in this context, but sharing global data should 
be practical even in a compute intensive application like Csound with up to 
dozens of threads. Beyond that, a more radical redesign will be required (we 
will see hundreds or even thousands of cores in 5 or 10 years...).

I agree with your comments about partitioning. I have not looked at the code 
in enough detail yet to see how difficult it would be to hoist the 
partioning up out of kperf itself, but I will give it a glance.

On a separate note, have you looked at this: http://www.rubato.org?

Regards,
Mike



----- Original Message ----- 
From: "Steven Yi" 
To: "Michael Gogins" ; "Developer discussions" 

Sent: Thursday, May 29, 2008 1:38 PM
Subject: Re: [Cs-dev] Threading


> Hi Michael,
>
> To run with multiple threads, use --num-threads=x  where x is the
> number of threads to use (probably start off with x = num cores and
> try out different values there).  Not setting --num-threads defaults
> to 1 and therefore defaults to using the old scheduler and kperf.  For
> the ORC, we do not currently have support for any goto's, including
> any if's.  At least, not without using the mutex opcodes
> (http://www.nabble.com/Mutlithreaded-Csound-to9823048.html#a9823048).
> The code for the mutex ops are in Opcodes/mutexops.c.  I think you
> just give a mutex number to lock on, and the mutex opcodes will create
> a mutex and lock and unlock on that mutex.  You should also be able to
> do multiple locks and unlocks.
>
> I would suggest for just testing purposes now for performance to try
> out with very simple orchestras.
>
> Besides the problems with ifs/gotos, we need to see what other code is
> referencing CURREVT and any other "global" variable that is held in
> the Csound struct.  If we are going to pursue this seriously, I think
> we should aim to remove fields from the Csound struct that are global
> like this and break API compatibility, or at minimum, disable locally
> and remove all references and reenable to check in with a comment that
> it no longer should be used, if we want to maintain API compatibility.
> I'm for breaking API compatibility in this regard as I wouldn't want
> anyone in the future to try to use these values, but don't see a
> problem to stick with compatibility for now.
>
> Also, the work partition is done on each kperf which was done to work
> with the data structure that events are currently stored in (a long
> linked-list, sorted by instr num).  I think we would get benefit to
> instead do the work partition when events are added to the work queue
> and to pre-separate the work into different queues.  That way kperf
> won't have to repartition every pass but instead just do the work.
>
> Otherwise, doing a CVS update now and will try it out here on WinXP!
> steven
>
>
> On Thu, May 29, 2008 at 10:17 AM, Michael Gogins  
> wrote:
>> Now that I have replaced Windows threading with Posix threads (pthreads) 
>> in the Windows build of Csound, and a cursory test says it still works, I 
>> have questions.
>>
>> How do I enable the multi-threading option when rendering with Csound?
>>
>> Is there anything special I have to do, or not do, in my orc file?
>>
>> Regards,
>> Mike
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net