Tried the new code with --num-threads on a dual PPC G5 and I
got crashes an all attempts. The one that seemed to go a little
further before crashing actually gave me a worse performance
than the uni-thread run.

I tried it with trapped.csd and xanadu.csd, both crashing on
early stages. Then I tried with my mouvements piece and that
went on to about 45 secs of score performance  before giving me
a bus error.

Victor

At 07:16 05/04/2007, you wrote:
>I think the flag I put in is --num-threads and it should be set like
>"--num-threads=2".  Beyond that, nothing special to do.  I've gotten
>some intermittent segfaults with it, though it seems less when writing
>to disk than to DAC.
>
>Thanks!
>steven
>
>
>On 4/4/07, Victor Lazzarini  wrote:
>>I might be able to run a quick test tomorrow on a
>>dual-processor. Is there anything special, apart
>>from setting --num-processors  that I should do?
>>
>>Thanks
>>
>>Victor
>> >
>> > hi victor,
>> >
>> > thanks for taking a look at the mac side!  hope you'll
>> > have a chance to test on a multi-core machine to see how
>> > it performs!
>> >
>> > steven
>> >
>> > On 4/4/07, Victor Lazzarini 
>> > > wrote: well, it appears that the barrier code is OK for
>> > > the Mac as it's basic pthread-based. So I have
>> > > tentatively committed it as well. Will need testing, but
>> > > it should work as it does on Linux.
>> > >
>> > > Now we just need to do the same for Win3-threads.
>> > >
>> > > Victor
>> > >
>> > > >
>> > > > Hi All,
>> > > >
>> > > > I've just checked into CVS an initial attempt at
>> > > > getting csound multithreaded.  John and I had talked a
>> > > > little at the LAC about starting to move towards
>> > > > taking advantage of multicore systems.  The
>> > > > implementation uses some code for thread barriers that
>> > > > John sent me to use as a reference and currently is
>> > > > implemented on Linux and has stubs there for Mac and
>> > > > Windows (in threads.c).  While at LAC and thinking
>> > > > about how to multithread, I got to thinking about the
>> > > > processing order and semantics of that.  To preserve
>> > > > the same exact order of processing as the
>> > single-threaded version, I figured for an initial
>> > > > implementation to do that is to basically have a
>> > > > thread pool and process each set of instrument
>> > > > instances one at a time, i.e. processing all of instr
>> > > > 1, then instr 2, etc.  kperf was changed when
>> > > > --num-threads=2 or more to use barriers to call the
>> > worker threads and wait on a barrier for them to finish.
>> > > > For code in instruments which may cause race
>> > > > conditions, a set of mutex opcodes were written:
>> > > > mutex_lock, mutex_unlock, mutex_locki, and
>> > > > mutex_unlocki.  I'm not sure the i-rate versions are
>> > > > necessary though as i-time still processes all in a
>> > > single thread, so those might be unnecessary. >
>> > > > The strategy is a bit naive and inefficient, though I
>> > > > don't know really what the performance is like as I
>> > > > only have a single core machine.  I'd be very
>> > > > interested to know how the performance is like on a
>> > > multi-core machine. >
>> > > > Also, right now I find that using multiple threads can
>> > > > yield segfaults.  I haven't had much time to look at
>> > > > this as I've been away doing some work and only doing
>> > > > this in the little spare free time i have at the
>> > > > moment, and probably won't have much free time for
>> > > > another couple weeks.
>> > > >
>> > > > I don't expect this code and strategy to be optimal in
>> > > > any way or that it will yield any performance benefit
>> > > > in the end, but I thought it would be worth it to try
>> > > > out with a pretty conservative strategy with explicit
>> > > > user input for mutex locking, just to have some place
>> > > > to start from. It'd be great to get some other eyes on
>> > > > this code and thoughts on how to improve it.
>> > > >
>> > > > Thanks!
>> > > > steven
>> > > >
>> > > >
>> > > >
>> > ----------------------------------------------------------
>> > > > --------------- Take Surveys. Earn Cash. Influence the
>> > > > Future of IT Join SourceForge.net's Techsay panel and
>> > > > you'll get the chance to share your opinions on IT &
>> > > business topics through brief surveys-and earn cash >
>> > >
>> >
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> > > > _______________________________________________
>> > > > Csound-devel mailing list
>> > > > Csound-devel@lists.sourceforge.net
>> > > >
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> > > >
>> > ----------------------------------------------------------
>> > > --------------- Take Surveys. Earn Cash. Influence the
>> > > Future of IT Join SourceForge.net's Techsay panel and
>> > > you'll get the chance to share your opinions on IT &
>> > > business topics through brief surveys-and earn cash
>> >
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> > > _______________________________________________
>> > > Csound-devel mailing list
>> > > Csound-devel@lists.sourceforge.net
>> > >
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>> > >
>> >
>> > ----------------------------------------------------------
>> > --------------- Take Surveys. Earn Cash. Influence the
>> > Future of IT Join SourceForge.net's Techsay panel and
>> > you'll get the chance to share your opinions on IT &
>> > business topics through brief surveys-and earn cash
>> >
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>> > _______________________________________________
>> > Csound-devel mailing list
>> > Csound-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys-and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>_______________________________________________
>>Csound-devel mailing list
>>Csound-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net