Hi everyone,

today while playing a bit with the MonoPolySynth (available on Iain McCurdy's site as well as my own), I noticed that I have only one CPU that is being used. Can this be changed in order to improve performance?

I have a dual core, specs here:

brian@brian-kxstudio:~/CsoundStuff$ sudo lshw -short
H/W path        Device       Class       Description
====================================================
                             system      BM5242(BM5342,BM5642) (To Be Filled By O.E.M.)
/0                           bus         BM5242(BM5342,BM5642)
/0/0                         memory      64KiB BIOS
/0/4                         processor   Pentium(R) Dual-Core  CPU      E5800  @ 3.20GHz
/0/4/5                       memory      64KiB L1 cache
/0/4/6                       memory      2MiB L2 cache
/0/4/1.1                     processor   Logical CPU
/0/4/1.2                     processor   Logical CPU
/0/27                        memory      4GiB System Memory
/0/27/0                      memory      2GiB DIMM Synchronous 800 MHz (1.2 ns)
/0/27/1                      memory      2GiB DIMM Synchronous 800 MHz (1.2 ns)
/0/1                         processor   
/0/1/1.1                     processor   Logical CPU
/0/1/1.2                     processor   Logical CPU
/0/100                       bridge      4 Series Chipset DRAM Controller
/0/100/2                     display     4 Series Chipset Integrated Graphics Controller
/0/100/1b                    multimedia  NM10/ICH7 Family High Definition Audio Controller
/0/100/1c                    bridge      NM10/ICH7 Family PCI Express Port 1
/0/100/1c.1                  bridge      NM10/ICH7 Family PCI Express Port 2
/0/100/1c.1/0   eth0         network     RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
/0/100/1c.2                  bridge      NM10/ICH7 Family PCI Express Port 3
/0/100/1d                    bus         NM10/ICH7 Family USB UHCI Controller #1
/0/100/1d.1                  bus         NM10/ICH7 Family USB UHCI Controller #2
/0/100/1d.2                  bus         NM10/ICH7 Family USB UHCI Controller #3
/0/100/1d.3                  bus         NM10/ICH7 Family USB UHCI Controller #4
/0/100/1d.7                  bus         NM10/ICH7 Family USB2 EHCI Controller
/0/100/1e                    bridge      82801 PCI Bridge
/0/100/1f                    bridge      82801GB/GR (ICH7 Family) LPC Interface Bridge
/0/100/1f.1                  storage     82801G (ICH7 Family) IDE Controller
/0/100/1f.2                  storage     NM10/ICH7 Family SATA Controller [IDE mode]
/0/2            scsi2        storage     
/0/2/0.0.0      /dev/sda     disk        500GB ST3500413AS
/0/2/0.0.0/1    /dev/sda1    volume      463GiB EXT4 volume
/0/2/0.0.0/2    /dev/sda2    volume      2011MiB Extended partition
/0/2/0.0.0/2/5  /dev/sda5    volume      2011MiB Linux swap / Solaris partition
/0/3            scsi3        storage     
/0/3/0.1.0      /dev/cdrom1  disk        RAM GH75N
/0/5            scsi4        storage     
/0/5/0.0.0      /dev/sdb     disk        SCSI Disk
/0/5/0.0.1      /dev/sdc     disk        SCSI Disk

brian

Rory Walsh, Mar 29 2016:

> I think you can use -j N, where N is the number of cores. Although it's a
> little confusing as the manual states that "-j" writes an IRCAM type sound
> file?
The Csound program itself says, that lowercase j is for the jobs and uppercase J is for IRCAM files. Perhaps the manual had a typo?
...

Ta-ta
----
Ffanci
* Homepage: https://freeshell.de/~silvain
* Twitter:  http://twitter.com/ffanci_silvain
* GitHub:   https://github.com/fsilvain

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Sorry to highjack the question, but I've been wondering for ages, is
using a value of N higher than the number of cores problematic?

On Tue, Mar 29, 2016 at 10:37 AM, Rory Walsh  wrote:
> You're right! The manual uses an uppercase J for the Ircam stuff. I need to
> get my eyes checked! Still, I was surprised to see no mention of the -j
> option in the manual.
>
> On 29 March 2016 at 10:31, Ffanci Silvain  wrote:
>>
>> Rory Walsh, Mar 29 2016:
>>
>>> I think you can use -j N, where N is the number of cores. Although it's a
>>> little confusing as the manual states that "-j" writes an IRCAM type
>>> sound
>>> file?
>>
>> The Csound program itself says, that lowercase j is for the jobs and
>> uppercase J is for IRCAM files. Perhaps the manual had a typo?
>> ...
>>
>> Ta-ta
>> ----
>> Ffanci
>> * Homepage: https://freeshell.de/~silvain
>> * Twitter:  http://twitter.com/ffanci_silvain
>> * GitHub:   https://github.com/fsilvain
>>
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

Depends what you mea by problematic.  All my experiments say it works but 
at reducedspeed in N>cpus.  YMMV  of course.


On Tue, 29 Mar 2016, Peter Burgess wrote:

> Sorry to highjack the question, but I've been wondering for ages, is
> using a value of N higher than the number of cores problematic?
>
> On Tue, Mar 29, 2016 at 10:37 AM, Rory Walsh  wrote:
>> You're right! The manual uses an uppercase J for the Ircam stuff. I need to
>> get my eyes checked! Still, I was surprised to see no mention of the -j
>> option in the manual.
>>
>> On 29 March 2016 at 10:31, Ffanci Silvain  wrote:
>>>
>>> Rory Walsh, Mar 29 2016:
>>>
>>>> I think you can use -j N, where N is the number of cores. Although it's a
>>>> little confusing as the manual states that "-j" writes an IRCAM type
>>>> sound
>>>> file?
>>>
>>> The Csound program itself says, that lowercase j is for the jobs and
>>> uppercase J is for IRCAM files. Perhaps the manual had a typo?
>>> ...
>>>
>>> Ta-ta
>>> ----
>>> Ffanci
>>> * Homepage: https://freeshell.de/~silvain
>>> * Twitter:  http://twitter.com/ffanci_silvain
>>> * GitHub:   https://github.com/fsilvain
>>>
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>        https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>>
>>
>> Csound mailing list Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>> https://github.com/csound/csound/issues Discussions of bugs and features can
>> be posted here
>
>
>
> -- 
> http://algorythmradio.com
> https://soundcloud.com/algorythmradio
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

-j s in the manual under flags; just adjusting the words a little.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Thanks guys! Using -j seemed to do the trick.:)

brian

On Tue, 29 Mar 2016 10:37:27 +0100, Rory Walsh wrote:

You're right! The manual uses an uppercase J for the Ircam stuff. I need to get my eyes checked! Still, I was surprised to see no mention of the -j option in the manual.  

On 29 March 2016 at 10:31, Ffanci Silvain <silvain@freeshell.de> wrote:

Rory Walsh, Mar 29 2016:

I think you can use -j N, where N is the number of cores. Although it's a
little confusing as the manual states that "-j" writes an IRCAM type sound
file?

The Csound program itself says, that lowercase j is for the jobs and uppercase J is for IRCAM files. Perhaps the manual had a typo?
...

Ta-ta
----
Ffanci
* Homepage: https://freeshell.de/~silvain
* Twitter:  http://twitter.com/ffanci_silvain
* GitHub:   https://github.com/fsilvain

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
       https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here

i must say i am not very happy about the multicore processing capabilities of
Csound. That is from a user's perspective  - 

I have an old computer (year 2008, dual core, 3,2Ghz) and i run Csound as a
standard at ksmps=32. Not to high, still great for envelopes and such.
Using more than 1 core slows down the realtime process.
Bying a new 8 core won't speed up Csound because it will still use one core.

I think it 's weird that in nearly 10 years not much has changed in terms of
speed. Or am i wrong?

I hesitate to invest in a new computer as i don't think Csound will run
faster...



--
View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748239.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I'm going to be away from my pc for a bit today so I won't be able to participate initially, but I would like to discuss this a bit too, as I would really like to incorporate Csound and Cabbage much more than I have been in my music. I often don't use them because I would need to make changes to the options sections of each instrument, a long task for sure!

Anyway, I love both applications and I love the quality of the oscillators, everything. With so many options and so much control, it's not easy and takes time to really get "into" it, esp. for non-programmers like me! :)

brian

On Tue, 29 Mar 2016 04:56:44 -0700, Menno Knevel wrote:

i must say i am not very happy about the multicore processing capabilities of
Csound. That is from a user's perspective  - 

I have an old computer (year 2008, dual core, 3,2Ghz) and i run Csound as a
standard at ksmps=32. Not to high, still great for envelopes and such.
Using more than 1 core slows down the realtime process.
Bying a new 8 core won't speed up Csound because it will still use one core.

I think it 's weird that in nearly 10 years not much has changed in terms of
speed. Or am i wrong?

I hesitate to invest in a new computer as i don't think Csound will run
faster...



--
View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748239.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

I use a number of 4-core processors and yes speed in Hertz has barely 
changed in the time since 2009 (main computer) and this laptop (2014)
What has changed is SSD disks which make the laptop fast.

The paper I gave at the St Petersburg conference tried to address how to 
get performance from multicore; for example use of a-rate envelopes and 
--sample-accurate and also incorporaing reverbs into instruments.  Need to 
distill this into a suggestion-list.

I am tempted to say if you are not happ wit it, build a better model or 
design....

If you want speed for PVS for example the way is GPGPUs and Victor's 
experimental opcodes, and there are a few ewdeas floating about.

Sopeedup is possible thoug:
\begin{table}[tdp]
\begin{tabular}{|c|c|cc|ccc|}
\hline
{\small -j }& {\small CloudStrata} &  {\small Xanadu }& & {\small 
Trapped...} &
& \\
       &  {\tiny ksmps=500 (sr=96000)} & {\tiny ksmps=10 } & {\tiny 
ksmps=100 } &
  {\tiny ksmps=10 } & {\tiny ksmps=100 }& {\tiny ksmps=1000 }\\
\hline

1    &    1      &   1     & 1     &    1     &    1    &  1\\
2    &    0.54   &   0.57  & 0.55  &    0.75  &    0.79 &  0.78\\
3    &    0.39   &   0.40  & 0.40  &   0.66   &    0.76 &  0.73\\
4    &    0.32   &   0.39  & 0.33  &   0.61   &    0.72 &  0.70\\
\hline
\end{tabular}
\caption{Relative times for processor number and {\tt ksmps}}
   \label{results}
\end{table}

==John ff

  On Tue, 29 Mar 2016, Menno Knevel wrote:

> i must say i am not very happy about the multicore processing capabilities of
> Csound. That is from a user's perspective  -
>
> I have an old computer (year 2008, dual core, 3,2Ghz) and i run Csound as a
> standard at ksmps=32. Not to high, still great for envelopes and such.
> Using more than 1 core slows down the realtime process.
> Bying a new 8 core won't speed up Csound because it will still use one core.
>
> I think it 's weird that in nearly 10 years not much has changed in terms of
> speed. Or am i wrong?
>
> I hesitate to invest in a new computer as i don't think Csound will run
> faster...
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748239.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

@john

"Depends what you mea by problematic.  All my experiments say it works
but at reducedspeed in N>cpus.  YMMV  of course."


So setting too high a value of N will make it run slower than if you
used the correct number?

On Tue, Mar 29, 2016 at 11:06 AM, jpff  wrote:
> Depends what you mea by problematic.  All my experiments say it works but at
> reducedspeed in N>cpus.  YMMV  of course.
>
>
>
> On Tue, 29 Mar 2016, Peter Burgess wrote:
>
>> Sorry to highjack the question, but I've been wondering for ages, is
>> using a value of N higher than the number of cores problematic?
>>
>> On Tue, Mar 29, 2016 at 10:37 AM, Rory Walsh  wrote:
>>>
>>> You're right! The manual uses an uppercase J for the Ircam stuff. I need
>>> to
>>> get my eyes checked! Still, I was surprised to see no mention of the -j
>>> option in the manual.
>>>
>>> On 29 March 2016 at 10:31, Ffanci Silvain  wrote:
>>>>
>>>>
>>>> Rory Walsh, Mar 29 2016:
>>>>
>>>>> I think you can use -j N, where N is the number of cores. Although it's
>>>>> a
>>>>> little confusing as the manual states that "-j" writes an IRCAM type
>>>>> sound
>>>>> file?
>>>>
>>>>
>>>> The Csound program itself says, that lowercase j is for the jobs and
>>>> uppercase J is for IRCAM files. Perhaps the manual had a typo?
>>>> ...
>>>>
>>>> Ta-ta
>>>> ----
>>>> Ffanci
>>>> * Homepage: https://freeshell.de/~silvain
>>>> * Twitter:  http://twitter.com/ffanci_silvain
>>>> * GitHub:   https://github.com/fsilvain
>>>>
>>>>
>>>> Csound mailing list
>>>> Csound@listserv.heanet.ie
>>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>>> Send bugs reports to
>>>>        https://github.com/csound/csound/issues
>>>> Discussions of bugs and features can be posted here
>>>
>>>
>>>
>>> Csound mailing list Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
>>> https://github.com/csound/csound/issues Discussions of bugs and features
>>> can
>>> be posted here
>>
>>
>>
>>
>> --
>> http://algorythmradio.com
>> https://soundcloud.com/algorythmradio
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>        https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>>
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here

I assure you that i am grateful for the way that you and other developers of
Csound are working on improving the speed of Csound - and that i, as a user
can benefit from it. I am not a developer at all and can only "wait" for
what is going to happen...

I found a paper that you and others have written (ICMC 2015), yet have to
locate yours but perhaps it is the same paper.

I have no intention at all to complain about Csound and the developers, but
am surprised that after all these years it may not be worth the trouble to
invest in a new computer system, and i can stick with the old one.

I have seen the efforts of Victor to create some PVS opcodes for the GPU,
but unfortunately i could not succesfully install the cuda drivers on my
system yet (Linux Mint). It is still on my todo list though.

Another idea for something that is without a doubt easier said than done: as
a "simple" user (without being plagued by any knowledge on the intensity of
the job), i think: why not build a software system so that the GPU of the
videocard can do all of the Csound processing? 
An investment in a big videocard (250 euro) is perhaps be more interesting
than buying a new computer system?
How bizarre is this idea?




--
View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748245.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

The manual I read if not there -- I use the version in the github git 
repositorym and as bee there since at least last June

51b9df23 (John ffitch    2015-06-02 20:48:37 +0100 1024) 
-j NUM-j,
51b9df23 (John ffitch    2015-06-02 20:48:37 +0100 1026) 
--num-threads=NUM--num-threads=NUM
51b9df23 (John ffitch    2015-06-02 20:48:37 +0100 1027) 

51b9df23 (John ffitch    2015-06-02 20:48:37 +0100 1028) 

51b9df23 (John ffitch    2015-06-02 20:48:37 +0100 1029) 
Make NUM processes available for
51b9df23 (John ffitch    2015-06-02 20:48:37 +0100 1030) 
rendering.  This is only advantageous if the number of
b9ee694f (John ffitch    2016-03-29 12:43:07 +0100 1031) 
processors on the computer is the same or more that the number
94606d8a (John ffitch    2015-06-02 20:53:41 +0100 1032)               of 
requested processes.  It also may slow rendering down
51b9df23 (John ffitch    2015-06-02 20:48:37 +0100 1033)               if 
ksmps is too small.
51b9df23 (John ffitch    2015-06-02 20:48:37 +0100 1034) 

51b9df23 (John ffitch    2015-06-02 20:48:37 +0100 1035) 

51b9df23 (John ffitch    2015-06-02 20:48:37 +0100 1036) 


No idea about gitub.io -- neer been tere


On Tue, 29 Mar 2016, Rory Walsh wrote:

> I can't find it
> here:https://csound.github.io/docs/manual/CommandFlagsCategory.html
> 
> 
> On 29 March 2016 at 11:31, jpff  wrote:
>       -j s in the manual under flags; just adjusting the words a little.
>
>       Csound mailing list
>       Csound@listserv.heanet.ie
>       https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>       Send bugs reports to
>              https://github.com/csound/csound/issues
>       Discussions of bugs and features can be posted here
> 
> 
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

hi menno -

one thing i did not understand from your previous email.  you said: if 
you buy a 8 core machine now, you still only can use one core.

why?  if i understood brian correctly, he experiences a reasonable 
speedup when using 4 cores?

best -
	joachim


On 29/03/16 16:25, Menno Knevel wrote:
> I assure you that i am grateful for the way that you and other developers of
> Csound are working on improving the speed of Csound - and that i, as a user
> can benefit from it. I am not a developer at all and can only "wait" for
> what is going to happen...
>
> I found a paper that you and others have written (ICMC 2015), yet have to
> locate yours but perhaps it is the same paper.
>
> I have no intention at all to complain about Csound and the developers, but
> am surprised that after all these years it may not be worth the trouble to
> invest in a new computer system, and i can stick with the old one.
>
> I have seen the efforts of Victor to create some PVS opcodes for the GPU,
> but unfortunately i could not succesfully install the cuda drivers on my
> system yet (Linux Mint). It is still on my todo list though.
>
> Another idea for something that is without a doubt easier said than done: as
> a "simple" user (without being plagued by any knowledge on the intensity of
> the job), i think: why not build a software system so that the GPU of the
> videocard can do all of the Csound processing?
> An investment in a big videocard (250 euro) is perhaps be more interesting
> than buying a new computer system?
> How bizarre is this idea?
>
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748245.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>          https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Menno, I've helped a tiny bit with these issues and have a fair amount of experience with multithreading. It very much depends on the ksmps and on the structure of the piece whether you get significant speedups. Fastest is many instances of the same instrument running compute intensive code for long notes at high ksmps. Change any of these things and the speedups fade. Use arate envelopes at ksmps 100. If performance is truly a priority you should experiment with different opcodes and instruments and even profile or instrument your pieces.

Best,
Mike

That's some really useful info, thanks mike! I never understood how
multithreading worked, I always just assumed it split all processing
equally.

On Wed, Mar 30, 2016 at 4:49 AM, Michael Gogins
 wrote:
> Menno, I've helped a tiny bit with these issues and have a fair amount of
> experience with multithreading. It very much depends on the ksmps and on the
> structure of the piece whether you get significant speedups. Fastest is many
> instances of the same instrument running compute intensive code for long
> notes at high ksmps. Change any of these things and the speedups fade. Use
> arate envelopes at ksmps 100. If performance is truly a priority you should
> experiment with different opcodes and instruments and even profile or
> instrument your pieces.
>
> Best,
> Mike
>
> On Mar 29, 2016 2:56 PM, "Menno Knevel"  wrote:
>>
>> i must say i am not very happy about the multicore processing capabilities
>> of
>> Csound. That is from a user's perspective  -
>>
>> I have an old computer (year 2008, dual core, 3,2Ghz) and i run Csound as
>> a
>> standard at ksmps=32. Not to high, still great for envelopes and such.
>> Using more than 1 core slows down the realtime process.
>> Bying a new 8 core won't speed up Csound because it will still use one
>> core.
>>
>> I think it 's weird that in nearly 10 years not much has changed in terms
>> of
>> speed. Or am i wrong?
>>
>> I hesitate to invest in a new computer as i don't think Csound will run
>> faster...
>>
>>
>>
>> --
>> View this message in context:
>> http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748239.html
>> Sent from the Csound - General mailing list archive at Nabble.com.
>>
>> Csound mailing list
>> Csound@listserv.heanet.ie
>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>> Send bugs reports to
>>         https://github.com/csound/csound/issues
>> Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here

hi,
i have done some systematic testing to get grip on Csound multi-core
processing, because i was not happy with the performance when using the
option -j2 and --sample-accurate on my composition: it slowed down the
performance, an Intel Dual Core 3.2GHz with Linux using Jack.

I have tested 4 compositions by writing the wave file to disk: 
 
I have tested with:
sr = 48000
ksmps = 32
nchnls = 2

and 

sr = 48000
ksmps = 128
nchnls = 2

with these options:
- -W -o "xxx.wav"
- -W -o "xxx.wav" -j2 --sample-accurate

These are the results:
-----
Claudstrata.csd       real     CPU    options: - -W -o "xxx.wav"
ksmps = 32           135     129
ksmps = 128         120     117

Claudstrata.csd       real     CPU    options: - -W -o "xxx.wav" -j2
--sample-accurate
ksmps = 32           54       97
ksmps = 128         47       84

-----
Xanadu.csd           real     CPU    options: - -W -o "xxx.wav"
ksmps = 32           13      12
ksmps = 128         11      11

Xanadu.csd           real     CPU    options: - -W -o "xxx.wav" -j2
--sample-accurate
ksmps = 32            6       10
ksmps = 128         4.5      8

-----
Trapped.csd           real     CPU    options: - -W -o "xxx.wav"
ksmps = 32           11      10
ksmps = 128         8.4     8

Trapped.csd           real     CPU    options: - -W -o "xxx.wav" -j2
--sample-accurate
ksmps = 32            9       13.5
ksmps = 128          6       9

-----
Geviste.csd           real     CPU    options: - -W -o "xxx.wav"
ksmps = 32           111    108
ksmps = 128         101     98

Geviste.csd           real     CPU    options: - -W -o "xxx.wav" -j2
--sample-accurate
ksmps = 32          174     264
ksmps = 128        135     197

-----

Conclusion: Claudstrata, Xanadu and Trapped all benefit greatly from the
option -j2
My composition does not - in fact, it takes 50% more time to finish.

I have done this test because i would like to get a grip on when to use -j2
and when not, and why.

My composition Geviste.csd uses a lot of diskin2 opcodes (generated notes
with CMask). Perhaps another approach using another opcode would produce
much better result in my case?

I have attached my compostion Geviste.csd: Geviste.csd
  



--
View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748519.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

With --sample-accurate you also eed aa large ksmps -- otherwise the effect 
is minimal

On Mon, 4 Apr 2016, Menno Knevel wrote:

> hi,
> i have done some systematic testing to get grip on Csound multi-core
> processing, because i was not happy with the performance when using the
> option -j2 and --sample-accurate on my composition: it slowed down the
> performance, an Intel Dual Core 3.2GHz with Linux using Jack.
>
> I have tested 4 compositions by writing the wave file to disk:
>
> I have tested with:
> sr = 48000
> ksmps = 32
> nchnls = 2
>
> and
>
> sr = 48000
> ksmps = 128
> nchnls = 2
>
> with these options:
> - -W -o "xxx.wav"
> - -W -o "xxx.wav" -j2 --sample-accurate
>
> These are the results:
> -----
> Claudstrata.csd       real     CPU    options: - -W -o "xxx.wav"
> ksmps = 32           135     129
> ksmps = 128         120     117
>
> Claudstrata.csd       real     CPU    options: - -W -o "xxx.wav" -j2
> --sample-accurate
> ksmps = 32           54       97
> ksmps = 128         47       84
>
> -----
> Xanadu.csd           real     CPU    options: - -W -o "xxx.wav"
> ksmps = 32           13      12
> ksmps = 128         11      11
>
> Xanadu.csd           real     CPU    options: - -W -o "xxx.wav" -j2
> --sample-accurate
> ksmps = 32            6       10
> ksmps = 128         4.5      8
>
> -----
> Trapped.csd           real     CPU    options: - -W -o "xxx.wav"
> ksmps = 32           11      10
> ksmps = 128         8.4     8
>
> Trapped.csd           real     CPU    options: - -W -o "xxx.wav" -j2
> --sample-accurate
> ksmps = 32            9       13.5
> ksmps = 128          6       9
>
> -----
> Geviste.csd           real     CPU    options: - -W -o "xxx.wav"
> ksmps = 32           111    108
> ksmps = 128         101     98
>
> Geviste.csd           real     CPU    options: - -W -o "xxx.wav" -j2
> --sample-accurate
> ksmps = 32          174     264
> ksmps = 128        135     197
>
> -----
>
> Conclusion: Claudstrata, Xanadu and Trapped all benefit greatly from the
> option -j2
> My composition does not - in fact, it takes 50% more time to finish.
>
> I have done this test because i would like to get a grip on when to use -j2
> and when not, and why.
>
> My composition Geviste.csd uses a lot of diskin2 opcodes (generated notes
> with CMask). Perhaps another approach using another opcode would produce
> much better result in my case?
>
> I have attached my compostion Geviste.csd: Geviste.csd
> 
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748519.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

i see - i thought ksmps = 128 is already large.
I will try even larger settings.

Can the fact that my piece runs slower with -j2 enabled, be because of the
diskin2 opcode?s read from disk after all.
I mean will flooper or loscil be a faster option?

I'm trying to find a pattern here....



--
View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748527.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Sorry --#i am confused.  These results show speedup on all 4 examples. 
How could it be better?

I hope you are looking at elapsed (real) time and not CPU which is 
naturally higher with 2 priocessirs instead of 1.  The aim is 
time-to-solution not "efficiency"
==John


On Mon, 4 Apr 2016, Menno Knevel wrote:

> hi,
> i have done some systematic testing to get grip on Csound multi-core
> processing, because i was not happy with the performance when using the
> option -j2 and --sample-accurate on my composition: it slowed down the
> performance, an Intel Dual Core 3.2GHz with Linux using Jack.
>
> I have tested 4 compositions by writing the wave file to disk:
>
> I have tested with:
> sr = 48000
> ksmps = 32
> nchnls = 2
>
> and
>
> sr = 48000
> ksmps = 128
> nchnls = 2
>
> with these options:
> - -W -o "xxx.wav"
> - -W -o "xxx.wav" -j2 --sample-accurate
>
> These are the results:
> -----
> Claudstrata.csd       real     CPU    options: - -W -o "xxx.wav"
> ksmps = 32           135     129
> ksmps = 128         120     117
>
> Claudstrata.csd       real     CPU    options: - -W -o "xxx.wav" -j2
> --sample-accurate
> ksmps = 32           54       97
> ksmps = 128         47       84
>
> -----
> Xanadu.csd           real     CPU    options: - -W -o "xxx.wav"
> ksmps = 32           13      12
> ksmps = 128         11      11
>
> Xanadu.csd           real     CPU    options: - -W -o "xxx.wav" -j2
> --sample-accurate
> ksmps = 32            6       10
> ksmps = 128         4.5      8
>
> -----
> Trapped.csd           real     CPU    options: - -W -o "xxx.wav"
> ksmps = 32           11      10
> ksmps = 128         8.4     8
>
> Trapped.csd           real     CPU    options: - -W -o "xxx.wav" -j2
> --sample-accurate
> ksmps = 32            9       13.5
> ksmps = 128          6       9
>
> -----
> Geviste.csd           real     CPU    options: - -W -o "xxx.wav"
> ksmps = 32           111    108
> ksmps = 128         101     98
>
> Geviste.csd           real     CPU    options: - -W -o "xxx.wav" -j2
> --sample-accurate
> ksmps = 32          174     264
> ksmps = 128        135     197
>
> -----
>
> Conclusion: Claudstrata, Xanadu and Trapped all benefit greatly from the
> option -j2
> My composition does not - in fact, it takes 50% more time to finish.
>
> I have done this test because i would like to get a grip on when to use -j2
> and when not, and why.
>
> My composition Geviste.csd uses a lot of diskin2 opcodes (generated notes
> with CMask). Perhaps another approach using another opcode would produce
> much better result in my case?
>
> I have attached my compostion Geviste.csd: Geviste.csd
> 
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748519.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

No - my result shows a significant speedup for the 3 examples: Cloudstrata,
Trapped and Xanadu. This is consistent with the speedup numbers i see in
your paper ICMC 2015: The new developments in Csound 6.

Looking at example 4 (my song) shows a big slowdown when using -j2. And i am
trying to figure out why so that i can learn from it and avoid the use of
some opcodes - in the hope that i can achieve the same sonic result with
other opcodes, like flooper, but with such a speedup!  Flooper reads from
memory, diskin2 from disk; this might explain this significant slowdown. I
don't know, i guessing here...

I have done some further testing on my song, with sr=48000 

ksmps=32      no -j2    = real 111
ksmps=128      no -j2    = real 101

ksmps=32   with -j2 and --sample-accurate   = real 174   !!
ksmps=128   with -j2 and --sample-accurate   = real 135
ksmps=256   with -j2 and --sample-accurate   = real 142
ksmps=512   with -j2 and --sample-accurate   = real 124
ksmps=1024   with -j2 and --sample-accurate   = real 118

I was experiencing some hiccups when rendering to dac so tried the -j2
option. This actually slowed performance down.









--
View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748530.html
Sent from the Csound - General mailing list archive at Nabble.com.

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

It does depend on how many concurrent instruments you have, and on their 
interactions.  Without seeing the orchestra the best I an suggest is 
running with -v and look at the semantic analysis data.


On Mon, 4 Apr 2016, Menno Knevel wrote:

> No - my result shows a significant speedup for the 3 examples: Cloudstrata,
> Trapped and Xanadu. This is consistent with the speedup numbers i see in
> your paper ICMC 2015: The new developments in Csound 6.
>
> Looking at example 4 (my song) shows a big slowdown when using -j2. And i am
> trying to figure out why so that i can learn from it and avoid the use of
> some opcodes - in the hope that i can achieve the same sonic result with
> other opcodes, like flooper, but with such a speedup!  Flooper reads from
> memory, diskin2 from disk; this might explain this significant slowdown. I
> don't know, i guessing here...
>
> I have done some further testing on my song, with sr=48000
>
> ksmps=32      no -j2    = real 111
> ksmps=128      no -j2    = real 101
>
> ksmps=32   with -j2 and --sample-accurate   = real 174   !!
> ksmps=128   with -j2 and --sample-accurate   = real 135
> ksmps=256   with -j2 and --sample-accurate   = real 142
> ksmps=512   with -j2 and --sample-accurate   = real 124
> ksmps=1024   with -j2 and --sample-accurate   = real 118
>
> I was experiencing some hiccups when rendering to dac so tried the -j2
> option. This actually slowed performance down.
>
>
>
>
>
>
>
>
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748530.html
> Sent from the Csound - General mailing list archive at Nabble.com.
>
> Csound mailing list
> Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
> Send bugs reports to
>        https://github.com/csound/csound/issues
> Discussions of bugs and features can be posted here
>

Csound mailing list
Csound@listserv.heanet.ie
https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
Send bugs reports to
        https://github.com/csound/csound/issues
Discussions of bugs and features can be posted here

Just as a side note.
If you split your orchestra into separate instruments and compile
Cabbage plugins, you can run each instrument (or subgruoup of
instruments) on separate tracks in a VST host (e.g. Reaper). Then the
host will split CPU load per track. We are working on a 64 bit version
of Hadron, and I did a test today, running 20 instances of Hadron
(each one on a separate track in Reaper. All 8 cores on my laptop was
actively processing, and the overall CPU load was 55%. My laptop is 2
years old (Dell M6800). Our Hadron-specific Csound build is a stripped
down version of the canonical build but in general the performance of
the canonical should be comparable.
I know this solution is not directly applicable for all Csound pieces,
and each Csound instance is running on a single core, so you
effectively need to segment the job into separate processes yourself.
I also know the multicore processing of Csound should be able to
distribute the processing load in a much better way than you could
ever do yourself manually. Still, for me, this was a test confirming
the utilization of all 8 cores in a realtime performance with more
juice than I had ever had before.
Oeyvind


2016-04-04 18:20 GMT+02:00 Justin Smith :
> OK, parts of that came out garbled - where I say opcode I think it's
> actually instrument. And the last question was whether individual threads
> can hit ksmps boundaries without coordinating with the other threads (if no,
> ksmps is a hard limit on your job size regardless of usage of global data).
>
> On Mon, Apr 4, 2016 at 9:14 AM Justin Smith  wrote:
>>
>> I do concurrent and parallel programming at my day job - this is a general
>> issue with coordinated parallel work. The smaller the size of the work you
>> do before coordination is needed, the more overhead the parallelism imposes
>> compared to a single threaded alternative. In csound the ksmps represents
>> the amount of work a single opcode does before returning to the csound
>> engine. There are aspects of an instrument that can require coordination
>> with other threads - if you change globally visible data, including g-vars
>> or tables. Also, I'm not sure if csound will even parallelize beyond the
>> ksmps boundary - can are all the threads kept to the same ksmps boundaries?
>> If so, ksmps size is a hard limit on your job size, regardless of whether
>> the data needs sync.
>>
>> On Mon, Apr 4, 2016 at 5:32 AM jpff  wrote:
>>>
>>> It does depend on how many concurrent instruments you have, and on their
>>> interactions.  Without seeing the orchestra the best I an suggest is
>>> running with -v and look at the semantic analysis data.
>>>
>>>
>>> On Mon, 4 Apr 2016, Menno Knevel wrote:
>>>
>>> > No - my result shows a significant speedup for the 3 examples:
>>> > Cloudstrata,
>>> > Trapped and Xanadu. This is consistent with the speedup numbers i see
>>> > in
>>> > your paper ICMC 2015: The new developments in Csound 6.
>>> >
>>> > Looking at example 4 (my song) shows a big slowdown when using -j2. And
>>> > i am
>>> > trying to figure out why so that i can learn from it and avoid the use
>>> > of
>>> > some opcodes - in the hope that i can achieve the same sonic result
>>> > with
>>> > other opcodes, like flooper, but with such a speedup!  Flooper reads
>>> > from
>>> > memory, diskin2 from disk; this might explain this significant
>>> > slowdown. I
>>> > don't know, i guessing here...
>>> >
>>> > I have done some further testing on my song, with sr=48000
>>> >
>>> > ksmps=32      no -j2    = real 111
>>> > ksmps=128      no -j2    = real 101
>>> >
>>> > ksmps=32   with -j2 and --sample-accurate   = real 174   !!
>>> > ksmps=128   with -j2 and --sample-accurate   = real 135
>>> > ksmps=256   with -j2 and --sample-accurate   = real 142
>>> > ksmps=512   with -j2 and --sample-accurate   = real 124
>>> > ksmps=1024   with -j2 and --sample-accurate   = real 118
>>> >
>>> > I was experiencing some hiccups when rendering to dac so tried the -j2
>>> > option. This actually slowed performance down.
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > View this message in context:
>>> > http://csound.1045644.n5.nabble.com/Csnd-CPU-allocation-tp5748228p5748530.html
>>> > Sent from the Csound - General mailing list archive at Nabble.com.
>>> >
>>> > Csound mailing list
>>> > Csound@listserv.heanet.ie
>>> > https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> > Send bugs reports to
>>> >        https://github.com/csound/csound/issues
>>> > Discussions of bugs and features can be posted here
>>> >
>>>
>>> Csound mailing list
>>> Csound@listserv.heanet.ie
>>> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND
>>> Send bugs reports to
>>>         https://github.com/csound/csound/issues
>>> Discussions of bugs and features can be posted here
>
> Csound mailing list Csound@listserv.heanet.ie
> https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to
> https://github.com/csound/csound/issues Discussions of bugs and features can
> be posted here