Hi,
Is there somewhere information, relatively how much cpu power an opcode uses? In many (especially live) situations it would be really useful to know. Like for example how much difference on the resources are between oscil, oscil3 and poscil?
Even a rough estimation, like "heavy/medium/light/extra light" would help. 

Greetings,
Tarmo
Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

> Hi,
> Is there somewhere information, relatively how much cpu power an opcode
> uses? In many (especially live) situations it would be really useful to
> know. Like for example how much difference on the resources are between
> oscil, oscil3 and poscil?
> Even a rough estimation, like "heavy/medium/light/extra light" would help.
>

I have been collecting detailed information on thi sbut it is time
consumming.
Or you can use the cpu meter opcodes to deterinne....

Cannot reach the computer with the tables on it at present
but some data below (in instructions per sample and k-cycle)

==John


Opcode    &    init    & Audio    & Control \\
 \hline
table.a   &    93      &  23.063  & 43.998\\
table.k   &    93      & 0        &      45     \\
butterlp &     9       & 29.005 4 & 5.478 \\
butterhi &     19      & 30.000   & 35\\
butterbp &     20      & 30       & 71\\
bilbar   &   371.5     & 1856.028 & 86 \\
ags      &   497       & 917.921  & 79475.155 \\
oscil.kk &      69     & 12       & 47  \\
oscili.kk &     69     & 21       & 49   \\
reverb   &  6963.5     & 77       &  158 \\




Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

John's table properly formatted.


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"





On 2 Aug 2011, at 10:16, jpff@cs.bath.ac.uk wrote:

>> Hi,
>> Is there somewhere information, relatively how much cpu power an  
>> opcode
>> uses? In many (especially live) situations it would be really  
>> useful to
>> know. Like for example how much difference on the resources are  
>> between
>> oscil, oscil3 and poscil?
>> Even a rough estimation, like "heavy/medium/light/extra light"  
>> would help.
>>
>
> I have been collecting detailed information on thi sbut it is time
> consumming.
> Or you can use the cpu meter opcodes to deterinne....
>
> Cannot reach the computer with the tables on it at present
> but some data below (in instructions per sample and k-cycle)
>
> ==John
>
>
> Opcode    &    init    & Audio    & Control \\
> \hline
> table.a   &    93      &  23.063  & 43.998\\
> table.k   &    93      & 0        &      45     \\
> butterlp &     9       & 29.005 4 & 5.478 \\
> butterhi &     19      & 30.000   & 35\\
> butterbp &     20      & 30       & 71\\
> bilbar   &   371.5     & 1856.028 & 86 \\
> ags      &   497       & 917.921  & 79475.155 \\
> oscil.kk &      69     & 12       & 47  \\
> oscili.kk &     69     & 21       & 49   \\
> reverb   &  6963.5     & 77       &  158 \\
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie

I think it would be possible to add to Csound to instrument the opcode
routines with a cpu time log that would be sent to a socket or written
to a file.

It might also be possible to simply use the logs produced by a
profiler to do pretty much exactly the same thing.

Probably what John means by time consuming is simply setting up the
opcodes to get called. That could be daunting, given the number of
opcodes!  Perhaps it would be possible to scan the opcode type dump
and programmatically generate a Csound orchestra that would call
opcodes with dummy arguments and discard the results. That ought to be
enough to get timings. But I suspect writing such a script might be
harder than it seems.

Regards,
Mike

On Tue, Aug 2, 2011 at 10:41 AM, Dr. Richard Boulanger
 wrote:
> it would be great to publish these performance measures in the manual - with
> a date, cpu spec, etc.
> even if things change, we would still have a frame of reference.
> what do you think?
>
> Richard Boulanger, Ph.D.
> Professor of Electronic Production and Design
> Music Technology Division
> Berklee College of Music
> 1140 Boylston Street
> Boston, MA 02215
> 617-747-2485 (office)
> 774-488-9166 (cell)
> rboulanger@berklee.edu
> http://csounds.com/boulanger
> On Aug 2, 2011, at 6:27 AM, Victor Lazzarini wrote:
>
> John's table properly formatted.
>
>
> Send bugs reports to the Sourceforge bug tracker
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
> 
>
>
>
> On 2 Aug 2011, at 10:16, jpff@cs.bath.ac.uk wrote:
>
> Hi,
>
> Is there somewhere information, relatively how much cpu power an opcode
>
> uses? In many (especially live) situations it would be really useful to
>
> know. Like for example how much difference on the resources are between
>
> oscil, oscil3 and poscil?
>
> Even a rough estimation, like "heavy/medium/light/extra light" would help.
>
>
> I have been collecting detailed information on thi sbut it is time
>
> consumming.
>
> Or you can use the cpu meter opcodes to deterinne....
>
> Cannot reach the computer with the tables on it at present
>
> but some data below (in instructions per sample and k-cycle)
>
> ==John
>
>
> Opcode    &    init    & Audio    & Control \\
>
> \hline
>
> table.a   &    93      &  23.063  & 43.998\\
>
> table.k   &    93      & 0        &      45     \\
>
> butterlp &     9       & 29.005 4 & 5.478 \\
>
> butterhi &     19      & 30.000   & 35\\
>
> butterbp &     20      & 30       & 71\\
>
> bilbar   &   371.5     & 1856.028 & 86 \\
>
> ags      &   497       & 917.921  & 79475.155 \\
>
> oscil.kk &      69     & 12       & 47  \\
>
> oscili.kk &     69     & 21       & 49   \\
>
> reverb   &  6963.5     & 77       &  158 \\
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>
>           https://sourceforge.net/tracker/?group_id=81968&atid=564599
>
> Discussions of bugs and features can be posted here
>
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
>



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


Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

> I think it would be possible to add to Csound to instrument the opcode
> routines with a cpu time log that would be sent to a socket or written
> to a file.
>
> It might also be possible to simply use the logs produced by a
> profiler to do pretty much exactly the same thing.
>
> Probably what John means by time consuming is simply setting up the
> opcodes to get called. That could be daunting, given the number of
> opcodes!  Perhaps it would be possible to scan the opcode type dump
> and programmatically generate a Csound orchestra that would call
> opcodes with dummy arguments and discard the results. That ought to be
> enough to get timings. But I suspect writing such a script might be
> harder than it seems.

Apologies for short messages -- having a connectivity problem here at ICMC

My numbers come from valgrind, and the time consuming stuff is simply that
the tool that decodes the counts does not allow for cut-n-paste so the
numbers have to be copied.  I run twice, with different k-rates so i can
solve the equatuons for k-rate and a-rate instructions.  Thtat part of the
program is easy.  It is decodeing the valgrand raw data that has flawed me
so far.  could not find a student willing to do this as a project.

I ned hese numbers for load-balance in ParCS

back to fighting networks & ssh

==John



Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"

Found them
Need some care in use!

*.ak:           0       6       15
*.ka:           0       6       15
*.kk:           0       0       9
+.aa:           0       6       16
+.kk:            0      0       9
/.kk:           0       0       9
=.i             7
=.k:            0       0       7
init:           0       4       12
arand:          52      -0.351226       188.512264
balance:        38      2.351111        274.488889
buzz:           75      -0.639775       430.385596
cpspch:         106.368056
delay:          4097    -0.340018       157.403009
expon.k:        178.553846      0        9
expseg.a:       669.121622     5.000011 37
expseg.k:       669.121622     0.000031 26
foscil:         81      29       72
frac.i:         65
gbuzz:          77      64.000105 125.499682
int.i:          67
line.k:         20             0.000762 8.992379
linen.k:        62             0.000004 20.650515
linseg.k:       266.971564     0.000559 29.994448
octpch.1:       74
oscil.ka:       69      17       46
oscil.kk:       69      0        41
oscil.kk:       69      12       47
oscili.kk:      69      21       49
outs:           0       9.563279 21.655083
phasor.a:       38      15.979998 32.000007
phasor.k:       38      -0.000798 27
randh.k:        60      0.058034 34.004509
randi.k:        76      0.015561 35.999951
rassign:        2
reson:          39      13.002546 99.545002
reverb:         6963.481481       77.038957 157.999993
subkk:          0       0        9
table.a:        93      23.062626 43.997796
table.k:        93      0        45
tablei.k:       93      0        61
upsamp:         0       4        12

ags:            497     917.921440 79475.154651
nlfilt:         1068.813496     52.985889 100.158886
vdelay:         2073.886076     53.572573 69.049966
butterlp:       19       29.005359 45.478359
butterhi:       19       30.000387 35
butterbp:       20       30     71
zar:            14       1      41
aasign:         0        1      15
zacl:           14      51      54
/.ak:           0       6       20
zaw:            14      1.000018 38.998197
integrate:      13      5       17
zkr:            14      0       32
zkw:            14      0       31.999964
zkcl:           14      0       101
reinit:         0       0       16335.400000
rms:            32      10      21
sqrt.i:         8
sqrt.k:         0       0       8
exp.i:          19.412868
exp.k:          0       0       19.412868
!=.i:           13
!=.k:           0       0       13
timout:         40     -0.002915 15.235836
kcgoto:         0      0.000022 8.758767
kgoto:          0       0       7
bilbar:         371.5   1856.028046 85.999807


And yes, Oevind is rioght that there is parameter dependency... which is
why not all the counts are integer
==John ff

>> I think it would be possible to add to Csound to instrument the opcode
>> routines with a cpu time log that would be sent to a socket or written
>> to a file.
>>
>> It might also be possible to simply use the logs produced by a
>> profiler to do pretty much exactly the same thing.
>>
>> Probably what John means by time consuming is simply setting up the
>> opcodes to get called. That could be daunting, given the number of
>> opcodes!  Perhaps it would be possible to scan the opcode type dump
>> and programmatically generate a Csound orchestra that would call
>> opcodes with dummy arguments and discard the results. That ought to be
>> enough to get timings. But I suspect writing such a script might be
>> harder than it seems.
>
> Apologies for short messages -- having a connectivity problem here at ICMC
>
> My numbers come from valgrind, and the time consuming stuff is simply that
> the tool that decodes the counts does not allow for cut-n-paste so the
> numbers have to be copied.  I run twice, with different k-rates so i can
> solve the equatuons for k-rate and a-rate instructions.  Thtat part of the
> program is easy.  It is decodeing the valgrand raw data that has flawed me
> so far.  could not find a student willing to do this as a project.
>
> I ned hese numbers for load-balance in ParCS
>
> back to fighting networks & ssh
>
> ==John
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>
>




Send bugs reports to the Sourceforge bug tracker
            https://sourceforge.net/tracker/?group_id=81968&atid=564599
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"