I discovered that there was a route through dag_consume that was not
correct wrt locks.  Not exactly sure what was wrong but I have a
simpler scheme that seems to overcome the problem (not in CVS yet).
  However I am seeing a real oddity in the creation of the DAG.  There
  are three instances on instr1, which has no side-effects, but it is
  given as a DAG of
Root1:  Instr1-1  Instr1-2
Root2:  Instr1-3
when I would expect three roots.  Not a serious error at this stage
but later I am seeing incorrect dag structures, unless I am failing to
understand the DAG structure.

For testing purposes I have replaced the spinlock in dag_consume
(dag->consume_spinlock) with a statically allocated mutex, so valgrind
--tool=drd can be used to debug.

Apart from this there are still known errors in (a?b:c) expressions.

I think I am going to have to deconstruct the DAG creation code

==John ffitch


------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Could you post (or commit to CVS) the Csound instruments/scores that
you are using to test ParCS? I am trying to build ParCS for Windows so
I can help out here. If I can't build it for Windows I will build it
for Linux (dual boot machine). Right now MinGW is not having m4sugar
or something like that.

Regards,
Mike

On Mon, Aug 16, 2010 at 11:19 AM, John ffitch  wrote:
> I discovered that there was a route through dag_consume that was not
> correct wrt locks.  Not exactly sure what was wrong but I have a
> simpler scheme that seems to overcome the problem (not in CVS yet).
>  However I am seeing a real oddity in the creation of the DAG.  There
>  are three instances on instr1, which has no side-effects, but it is
>  given as a DAG of
> Root1:  Instr1-1  Instr1-2
> Root2:  Instr1-3
> when I would expect three roots.  Not a serious error at this stage
> but later I am seeing incorrect dag structures, unless I am failing to
> understand the DAG structure.
>
> For testing purposes I have replaced the spinlock in dag_consume
> (dag->consume_spinlock) with a statically allocated mutex, so valgrind
> --tool=drd can be used to debug.
>
> Apart from this there are still known errors in (a?b:c) expressions.
>
> I think I am going to have to deconstruct the DAG creation code
>
> ==John ffitch
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have installed MSys bison, flex, and m4 but I get:

bison -d --report=itemset -p csound_orc -o Engine\csound_orcparse.c
Engine\csound_orc.y
Engine\csound_orc.y: conflicts: 34 shift/reduce
bison: cannot open file `/usr/share/bison/m4sugar/m4sugar.m4': No such
file or directory
scons: *** [Engine\csound_orcparse.c] Error 1
scons: building terminated because of errors.

Regards,
Mike

On Mon, Aug 16, 2010 at 11:19 AM, John ffitch  wrote:
> I discovered that there was a route through dag_consume that was not
> correct wrt locks.  Not exactly sure what was wrong but I have a
> simpler scheme that seems to overcome the problem (not in CVS yet).
>  However I am seeing a real oddity in the creation of the DAG.  There
>  are three instances on instr1, which has no side-effects, but it is
>  given as a DAG of
> Root1:  Instr1-1  Instr1-2
> Root2:  Instr1-3
> when I would expect three roots.  Not a serious error at this stage
> but later I am seeing incorrect dag structures, unless I am failing to
> understand the DAG structure.
>
> For testing purposes I have replaced the spinlock in dag_consume
> (dag->consume_spinlock) with a statically allocated mutex, so valgrind
> --tool=drd can be used to debug.
>
> Apart from this there are still known errors in (a?b:c) expressions.
>
> I think I am going to have to deconstruct the DAG creation code
>
> ==John ffitch
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

That must be a failure in teh packaging if bison.  on my Linux machine I have
/usr/share/bison/m4sugar/m4sugar.m4
and also
/usr/share/bison/m4sugar/foreach.m4

Not sure what they do; never seen them before

> I have installed MSys bison, flex, and m4 but I get:
>
> bison -d --report=itemset -p csound_orc -o Engine\csound_orcparse.c
> Engine\csound_orc.y
> Engine\csound_orc.y: conflicts: 34 shift/reduce
> bison: cannot open file `/usr/share/bison/m4sugar/m4sugar.m4': No such
> file or directory
> scons: *** [Engine\csound_orcparse.c] Error 1
> scons: building terminated because of errors.
>
> Regards,
> Mike



------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

strange: I'm sure I have built the new parser on a Windows machine  
before. Maybe try installing a different bison/flex?

Victor
On 16 Aug 2010, at 23:46, Michael Gogins wrote:

> I have installed MSys bison, flex, and m4 but I get:
>
> bison -d --report=itemset -p csound_orc -o Engine\csound_orcparse.c
> Engine\csound_orc.y
> Engine\csound_orc.y: conflicts: 34 shift/reduce
> bison: cannot open file `/usr/share/bison/m4sugar/m4sugar.m4': No such
> file or directory
> scons: *** [Engine\csound_orcparse.c] Error 1
> scons: building terminated because of errors.
>
> Regards,
> Mike
>
> On Mon, Aug 16, 2010 at 11:19 AM, John ffitch   
> wrote:
>> I discovered that there was a route through dag_consume that was not
>> correct wrt locks.  Not exactly sure what was wrong but I have a
>> simpler scheme that seems to overcome the problem (not in CVS yet).
>>  However I am seeing a real oddity in the creation of the DAG.  There
>>  are three instances on instr1, which has no side-effects, but it is
>>  given as a DAG of
>> Root1:  Instr1-1  Instr1-2
>> Root2:  Instr1-3
>> when I would expect three roots.  Not a serious error at this stage
>> but later I am seeing incorrect dag structures, unless I am failing  
>> to
>> understand the DAG structure.
>>
>> For testing purposes I have replaced the spinlock in dag_consume
>> (dag->consume_spinlock) with a statically allocated mutex, so  
>> valgrind
>> --tool=drd can be used to debug.
>>
>> Apart from this there are still known errors in (a?b:c) expressions.
>>
>> I think I am going to have to deconstruct the DAG creation code
>>
>> ==John ffitch
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 17/08/2010 09:27, jpff@cs.bath.ac.uk wrote:
> That must be a failure in teh packaging if bison.  on my Linux machine I have
> /usr/share/bison/m4sugar/m4sugar.m4
> and also
> /usr/share/bison/m4sugar/foreach.m4
>
> Not sure what they do; never seen them before
>

Sugar is the GUI environment for OLPC, so it may relate to that. Seems 
an unnecessary dependency for bison though.

Richard Dobson


------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Not OLPC but syntctic sugar I think

Actually part of autoconf and used by bison


> On 17/08/2010 09:27, jpff@cs.bath.ac.uk wrote:
>> That must be a failure in teh packaging if bison.  on my Linux machine I
>> have
>> /usr/share/bison/m4sugar/m4sugar.m4
>> and also
>> /usr/share/bison/m4sugar/foreach.m4
>>
>> Not sure what they do; never seen them before
>>
>
> Sugar is the GUI environment for OLPC, so it may relate to that. Seems
> an unnecessary dependency for bison though.
>
> Richard Dobson
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 17/08/2010 10:23, jpff@cs.bath.ac.uk wrote:
> Not OLPC but syntctic sugar I think
>
> Actually part of autoconf and used by bison
>
>

Ah, indeed, it shows up under autoconf on my Mac. As does bison, but the 
paths are slightly different from what was reported. This Mac does not 
have a folder /usr/share/bison,  though bison is clearly available. So 
maybe the install paths are not quite as standardised as expected? MSys 
could well use something different again.

Richard Dobson


------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think you are right, it is probably install paths. I will try find
if there is an m4sugar somewhere else on my system and put it where
expected, etc.

Thanks,
Mike

On Tue, Aug 17, 2010 at 6:08 AM, Richard Dobson
 wrote:
> On 17/08/2010 10:23, jpff@cs.bath.ac.uk wrote:
>> Not OLPC but syntctic sugar I think
>>
>> Actually part of autoconf and used by bison
>>
>>
>
> Ah, indeed, it shows up under autoconf on my Mac. As does bison, but the
> paths are slightly different from what was reported. This Mac does not
> have a folder /usr/share/bison,  though bison is clearly available. So
> maybe the install paths are not quite as standardised as expected? MSys
> could well use something different again.
>
> Richard Dobson
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I am using three tests mainly

examples/par.csd
example/xanadu.csd
examples/trapped.csd

==John ffitch

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Do you change the ksmps to a higher value in order to obtain a larger
granularity of work sharing? I haven't succeeded in building ParCS
yet, but I have run some tests with the existing Steven Yi code and
with my own modified version of Steven's code which uses OpenMP.

I find that ksmps has to get pretty high (hundreds) to overcome
threading overheads and produce performance gains with multiple cores,
but once the gains start showing up, they do seem to be linear with
number of physical cores. I'm finding about a 25% performance
improvement per physical core with ksmps of a few hundred, so with my
4 cores I get speedups of about 2 x. The "hyperthreading" logical
threads on the Intel CPU don't seem to either speed up or slow down
performance, i.e. --num-threads=8 runs about the same as
--num-threads=4.

I have been using xanadu.csd and a piece of mine, Cloud Strata (1998
ICMC), that uses a single fairly compute-intensive instrument. I will
put the csd for that into the examples directory CVS. I will also
start using par.csd.

I should have firm numbers to report later and I hope to be able to
look at ParCS very soon. The code I'm working with does no "costing"
except my modified OpenMP version doesn't invoke any threading calls
at all if there is only one instrument instance for a given insno. I
think that the "costing" is theoretically a very good idea, since the
response of performance to ksmps size indicates a fairly high
threading overhead per kperiod. It's also clear that the spinlocks
themselves involve very little overhead, so it's all down to managing
threads and barriers, and this part should be irreducible across all
implementations of multithreading in Csound.

In the meantime, I think we should go ahead and put spinlocks on all
data that needs synchronization, including Csound API calls, in all
branches, do you agree? That would be only, but all, situations where
is one thread writing and another thread reading the same data OR
multiple threads writing the same data.

I am much encouraged with this work! .

Regards,
Mike

On Tue, Aug 17, 2010 at 9:24 AM, John ff  wrote:
> I am using three tests mainly
>
> examples/par.csd
> example/xanadu.csd
> examples/trapped.csd
>
> ==John ffitch
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

your results regarding ksmp sizes make sense. Maybe we will need to  
devise a 2-level processing schedule, whereby we can have a low enough  
control rate, but a higher granularity so the thread overhead can be  
mininimised.

Victor

On 17 Aug 2010, at 15:08, Michael Gogins wrote:

> Do you change the ksmps to a higher value in order to obtain a larger
> granularity of work sharing? I haven't succeeded in building ParCS
> yet, but I have run some tests with the existing Steven Yi code and
> with my own modified version of Steven's code which uses OpenMP.
>
> I find that ksmps has to get pretty high (hundreds) to overcome
> threading overheads and produce performance gains with multiple cores,
> but once the gains start showing up, they do seem to be linear with
> number of physical cores. I'm finding about a 25% performance
> improvement per physical core with ksmps of a few hundred, so with my
> 4 cores I get speedups of about 2 x. The "hyperthreading" logical
> threads on the Intel CPU don't seem to either speed up or slow down
> performance, i.e. --num-threads=8 runs about the same as
> --num-threads=4.
>
> I have been using xanadu.csd and a piece of mine, Cloud Strata (1998
> ICMC), that uses a single fairly compute-intensive instrument. I will
> put the csd for that into the examples directory CVS. I will also
> start using par.csd.
>
> I should have firm numbers to report later and I hope to be able to
> look at ParCS very soon. The code I'm working with does no "costing"
> except my modified OpenMP version doesn't invoke any threading calls
> at all if there is only one instrument instance for a given insno. I
> think that the "costing" is theoretically a very good idea, since the
> response of performance to ksmps size indicates a fairly high
> threading overhead per kperiod. It's also clear that the spinlocks
> themselves involve very little overhead, so it's all down to managing
> threads and barriers, and this part should be irreducible across all
> implementations of multithreading in Csound.
>
> In the meantime, I think we should go ahead and put spinlocks on all
> data that needs synchronization, including Csound API calls, in all
> branches, do you agree? That would be only, but all, situations where
> is one thread writing and another thread reading the same data OR
> multiple threads writing the same data.
>
> I am much encouraged with this work! .
>
> Regards,
> Mike
>
> On Tue, Aug 17, 2010 at 9:24 AM, John ff  wrote:
>> I am using three tests mainly
>>
>> examples/par.csd
>> example/xanadu.csd
>> examples/trapped.csd
>>
>> ==John ffitch
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm trying to figure out what you mean -- you mean that if there are
16 lightweight instances in a layer for 4 threads, then each thread
does 4 instances in series?

Regards,
Mike

On Tue, Aug 17, 2010 at 10:17 AM, Victor Lazzarini
 wrote:
> your results regarding ksmp sizes make sense. Maybe we will need to
> devise a 2-level processing schedule, whereby we can have a low enough
> control rate, but a higher granularity so the thread overhead can be
> mininimised.
>
> Victor
>
> On 17 Aug 2010, at 15:08, Michael Gogins wrote:
>
>> Do you change the ksmps to a higher value in order to obtain a larger
>> granularity of work sharing? I haven't succeeded in building ParCS
>> yet, but I have run some tests with the existing Steven Yi code and
>> with my own modified version of Steven's code which uses OpenMP.
>>
>> I find that ksmps has to get pretty high (hundreds) to overcome
>> threading overheads and produce performance gains with multiple cores,
>> but once the gains start showing up, they do seem to be linear with
>> number of physical cores. I'm finding about a 25% performance
>> improvement per physical core with ksmps of a few hundred, so with my
>> 4 cores I get speedups of about 2 x. The "hyperthreading" logical
>> threads on the Intel CPU don't seem to either speed up or slow down
>> performance, i.e. --num-threads=8 runs about the same as
>> --num-threads=4.
>>
>> I have been using xanadu.csd and a piece of mine, Cloud Strata (1998
>> ICMC), that uses a single fairly compute-intensive instrument. I will
>> put the csd for that into the examples directory CVS. I will also
>> start using par.csd.
>>
>> I should have firm numbers to report later and I hope to be able to
>> look at ParCS very soon. The code I'm working with does no "costing"
>> except my modified OpenMP version doesn't invoke any threading calls
>> at all if there is only one instrument instance for a given insno. I
>> think that the "costing" is theoretically a very good idea, since the
>> response of performance to ksmps size indicates a fairly high
>> threading overhead per kperiod. It's also clear that the spinlocks
>> themselves involve very little overhead, so it's all down to managing
>> threads and barriers, and this part should be irreducible across all
>> implementations of multithreading in Csound.
>>
>> In the meantime, I think we should go ahead and put spinlocks on all
>> data that needs synchronization, including Csound API calls, in all
>> branches, do you agree? That would be only, but all, situations where
>> is one thread writing and another thread reading the same data OR
>> multiple threads writing the same data.
>>
>> I am much encouraged with this work! .
>>
>> Regards,
>> Mike
>>
>> On Tue, Aug 17, 2010 at 9:24 AM, John ff  wrote:
>>> I am using three tests mainly
>>>
>>> examples/par.csd
>>> example/xanadu.csd
>>> examples/trapped.csd
>>>
>>> ==John ffitch
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by
>>>
>>> Make an app they can't live without
>>> Enter the BlackBerry Developer Challenge
>>> http://p.sf.net/sfu/RIM-dev2dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Some results on OSX, Intel dualcore 2.8GHz, ParCS compiled from CVS  
this afternoon

The strange thing is with ksmps = 100

csound -n sheppard.csd   =>  0.450s, CPU: 0.432s

csound -n sheppard.csd -t 1  =>  24.936s, CPU: 24.853s

csound -n sheppard.csd -t 2  =>   12.478s, CPU: 12.430s

csound -n sheppard.csd -t 4  =>   6.239s, CPU: 6.218s

csound -n sheppard.csd -t 8  =>   3.128s, CPU: 3.111s

....

csound sheppard.csd -t 512  -o test.wav => real: 0.091s, CPU: 0.065s   
(!!!!!!!!!!!!!!!)



-o dac -d


0dbfs = 1 ; MAX AMPLITUDE IS 1.0 !!!!
ksmps=100

instr 1
idur = 120
kf   oscili 1,1/idur,3,p4
ka   oscili 1,1/idur,2,p4
asig oscili ka,kf*3000,1
       out asig/10
endin



f1 0 16384 10 1
f2 0 16384 20 6 1
f3 0 16384  5 1 16384 [2^-10]

i1 0  100  0
i1 0  100  0.1
i1 0  100  0.2
i1 0  100  0.3
i1 0  100  0.4
i1 0  100  0.5
i1 0  100  0.6
i1 0  100  0.7
i1 0  100  0.8
i1 0  100  0.9












------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I though that maybe thread sync could happen at a higher rate than kr;  
I guess what you describe is one way of going about it.

Victor


On 17 Aug 2010, at 15:42, Michael Gogins wrote:

> I'm trying to figure out what you mean -- you mean that if there are
> 16 lightweight instances in a layer for 4 threads, then each thread
> does 4 instances in series?
>
> Regards,
> Mike
>
> On Tue, Aug 17, 2010 at 10:17 AM, Victor Lazzarini
>  wrote:
>> your results regarding ksmp sizes make sense. Maybe we will need to
>> devise a 2-level processing schedule, whereby we can have a low  
>> enough
>> control rate, but a higher granularity so the thread overhead can be
>> mininimised.
>>
>> Victor
>>
>> On 17 Aug 2010, at 15:08, Michael Gogins wrote:
>>
>>> Do you change the ksmps to a higher value in order to obtain a  
>>> larger
>>> granularity of work sharing? I haven't succeeded in building ParCS
>>> yet, but I have run some tests with the existing Steven Yi code and
>>> with my own modified version of Steven's code which uses OpenMP.
>>>
>>> I find that ksmps has to get pretty high (hundreds) to overcome
>>> threading overheads and produce performance gains with multiple  
>>> cores,
>>> but once the gains start showing up, they do seem to be linear with
>>> number of physical cores. I'm finding about a 25% performance
>>> improvement per physical core with ksmps of a few hundred, so with  
>>> my
>>> 4 cores I get speedups of about 2 x. The "hyperthreading" logical
>>> threads on the Intel CPU don't seem to either speed up or slow down
>>> performance, i.e. --num-threads=8 runs about the same as
>>> --num-threads=4.
>>>
>>> I have been using xanadu.csd and a piece of mine, Cloud Strata (1998
>>> ICMC), that uses a single fairly compute-intensive instrument. I  
>>> will
>>> put the csd for that into the examples directory CVS. I will also
>>> start using par.csd.
>>>
>>> I should have firm numbers to report later and I hope to be able to
>>> look at ParCS very soon. The code I'm working with does no "costing"
>>> except my modified OpenMP version doesn't invoke any threading calls
>>> at all if there is only one instrument instance for a given insno. I
>>> think that the "costing" is theoretically a very good idea, since  
>>> the
>>> response of performance to ksmps size indicates a fairly high
>>> threading overhead per kperiod. It's also clear that the spinlocks
>>> themselves involve very little overhead, so it's all down to  
>>> managing
>>> threads and barriers, and this part should be irreducible across all
>>> implementations of multithreading in Csound.
>>>
>>> In the meantime, I think we should go ahead and put spinlocks on all
>>> data that needs synchronization, including Csound API calls, in all
>>> branches, do you agree? That would be only, but all, situations  
>>> where
>>> is one thread writing and another thread reading the same data OR
>>> multiple threads writing the same data.
>>>
>>> I am much encouraged with this work! .
>>>
>>> Regards,
>>> Mike
>>>
>>> On Tue, Aug 17, 2010 at 9:24 AM, John ff  wrote:
>>>> I am using three tests mainly
>>>>
>>>> examples/par.csd
>>>> example/xanadu.csd
>>>> examples/trapped.csd
>>>>
>>>> ==John ffitch
>>>>
>>>> ------------------------------------------------------------------------------
>>>> This SF.net email is sponsored by
>>>>
>>>> Make an app they can't live without
>>>> Enter the BlackBerry Developer Challenge
>>>> http://p.sf.net/sfu/RIM-dev2dev
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net email is sponsored by
>>>
>>> Make an app they can't live without
>>> Enter the BlackBerry Developer Challenge
>>> http://p.sf.net/sfu/RIM-dev2dev
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>
>
>
> -- 
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sorry, ignore results, I should have used -j instead of -t.

Victor
On 17 Aug 2010, at 15:47, Victor Lazzarini wrote:

> Some results on OSX, Intel dualcore 2.8GHz, ParCS compiled from CVS
> this afternoon
>
> The strange thing is with ksmps = 100
>
> csound -n sheppard.csd   =>  0.450s, CPU: 0.432s
>
> csound -n sheppard.csd -t 1  =>  24.936s, CPU: 24.853s
>
> csound -n sheppard.csd -t 2  =>   12.478s, CPU: 12.430s
>
> csound -n sheppard.csd -t 4  =>   6.239s, CPU: 6.218s
>
> csound -n sheppard.csd -t 8  =>   3.128s, CPU: 3.111s
>
> ....
>
> csound sheppard.csd -t 512  -o test.wav => real: 0.091s, CPU: 0.065s
> (!!!!!!!!!!!!!!!)
>
> 
> 
> -o dac -d
> 
> 
> 0dbfs = 1 ; MAX AMPLITUDE IS 1.0 !!!!
> ksmps=100
>
> instr 1
> idur = 120
> kf   oscili 1,1/idur,3,p4
> ka   oscili 1,1/idur,2,p4
> asig oscili ka,kf*3000,1
>       out asig/10
> endin
>
> 
> 
> f1 0 16384 10 1
> f2 0 16384 20 6 1
> f3 0 16384  5 1 16384 [2^-10]
>
> i1 0  100  0
> i1 0  100  0.1
> i1 0  100  0.2
> i1 0  100  0.3
> i1 0  100  0.4
> i1 0  100  0.5
> i1 0  100  0.6
> i1 0  100  0.7
> i1 0  100  0.8
> i1 0  100  0.9
>
>
> 
> 
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel


------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net