How expensive is that opcode?

[jpff]

I had a very interesting brain-storming session yesterday in
preparation for creating a multi-core Csound.  Part of the conclusion
was that we needed a table of approximate costs of each opcode.
So.... I have started to create such a table.  In doing this I realise
that users in general may not be aware of the relative costs.  I have
not done it yet but I suspect that
    a1 = k1*a2 + k2*a3
might be slower than
    a1   mac    k1,a2,k2,a3
but we do need to know.

I will measure more opcodes as I have time; currently rather a pain.
I can accept requests if provided with .csd files
==John ffitch

These are for ksmps = 10

+aa     => 76
+kk     => 9
arand   => 185
=       => 7
balance => 298
buzz =>423
cpspch =>106
delay =>154
/kk =>9
expseg =>87
foscil =>362
frac1 =>65
gbuzz =>765
int1 =>67
itblchk =>84
kexpon =>9
kline =>9
klinen =>20
klnseg =>30
koscil =>41
kphsor =>26
krandh =>34
krandi =>36
ktable =>45
ktabli =>61
kxpseg =>26
*ak =>75
*ka =>75
*kk =>9
octpch =>74
oscka =>216
osckk =>167
osckki =>259
outs =>117
phsor =>191
rassign =>2
reson =>229
reverb =>928
-kk =>9
tablefn =>274
upsamp =>52


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Oeyvind Brandtsegg-2]

Just a thought:
How would we do this for granular synthesis opcodes, that "cost more"
when using more overlaps (e.g. longer grains) ? The difference can be
significant, I guess almost linear growth in cost relative to the
number of overlaps.

Oeyvind

2008/6/12, jpff <jpff@...>:

> I had a very interesting brain-storming session yesterday in
> preparation for creating a multi-core Csound.  Part of the conclusion
> was that we needed a table of approximate costs of each opcode.
> So.... I have started to create such a table.  In doing this I realise
> that users in general may not be aware of the relative costs.  I have
> not done it yet but I suspect that
>    a1 = k1*a2 + k2*a3
> might be slower than
>    a1   mac    k1,a2,k2,a3
> but we do need to know.
>
> I will measure more opcodes as I have time; currently rather a pain.
> I can accept requests if provided with .csd files
> ==John ffitch
>
> These are for ksmps = 10
>
> +aa     => 76
> +kk     => 9
> arand   => 185
> =       => 7
> balance => 298
> buzz    =>423
> cpspch  =>106
> delay   =>154
> /kk     =>9
> expseg  =>87
> foscil  =>362
> frac1   =>65
> gbuzz   =>765
> int1    =>67
> itblchk =>84
> kexpon  =>9
> kline   =>9
> klinen  =>20
> klnseg  =>30
> koscil  =>41
> kphsor  =>26
> krandh  =>34
> krandi  =>36
> ktable  =>45
> ktabli  =>61
> kxpseg  =>26
> *ak     =>75
> *ka     =>75
> *kk     =>9
> octpch  =>74
> oscka   =>216
> osckk   =>167
> osckki  =>259
> outs    =>117
> phsor   =>191
> rassign =>2
> reson   =>229
> reverb  =>928
> -kk     =>9
> tablefn =>274
> upsamp  =>52
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe csound"
>

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Richard Bowers]

A really useful feature would be a cost calculator - something which you
could apply to a mute run of a csd file, maybe, or even as a running
report (k-rate opcode?). This would be especially useful if the problem
re granular synthesis is overcome because of the ability to change
parameters in realtime.

jpff wrote:

> I had a very interesting brain-storming session yesterday in
> preparation for creating a multi-core Csound.  Part of the conclusion
> was that we needed a table of approximate costs of each opcode.
> So.... I have started to create such a table.  In doing this I realise
> that users in general may not be aware of the relative costs.  I have
> not done it yet but I suspect that
>     a1 = k1*a2 + k2*a3
> might be slower than
>     a1   mac    k1,a2,k2,a3
> but we do need to know.
>
> I will measure more opcodes as I have time; currently rather a pain.
> I can accept requests if provided with .csd files
> ==John ffitch
>
> These are for ksmps = 10
>
> +aa     => 76
> +kk     => 9
> arand   => 185
> =       => 7
> balance => 298
> buzz =>423
> cpspch =>106
> delay =>154
> /kk =>9
> expseg =>87
> foscil =>362
> frac1 =>65
> gbuzz =>765
> int1 =>67
> itblchk =>84
> kexpon =>9
> kline =>9
> klinen =>20
> klnseg =>30
> koscil =>41
> kphsor =>26
> krandh =>34
> krandi =>36
> ktable =>45
> ktabli =>61
> kxpseg =>26
> *ak =>75
> *ka =>75
> *kk =>9
> octpch =>74
> oscka =>216
> osckk =>167
> osckki =>259
> outs =>117
> phsor =>191
> rassign =>2
> reson =>229
> reverb =>928
> -kk =>9
> tablefn =>274
> upsamp =>52
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@... with body "unsubscribe csound"
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG.
> Version: 8.0.100 / Virus Database: 270.3.0/1500 - Release Date: 6/12/2008 4:58 PM
>  

Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[jpff]

There are two major classes of opcode
The first class are the straightforward ones that have a cost as
    A + B*ksmps
and my current policy is to calculate A and B for a number of opcodes

The second class are the ones like granular synth where I suspect that
the cost is
    A + B*ksmps + B*x
for some x which is a parameter like overlap.  These are harder, but
either one needs to determine A, B, C and x, or one uses class one and
calculates a range for A and B.

But without this sane user-level parallelism is doomed as a useful
feature.

It may be best that this discussion is on the developer list?  I did
however want to draw attention of those real-time users that there are
sometimes better ways of calculating the same functionality.
==John ffitch


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[jpff]

>>>>> "Richard" == Richard Bowers <richard.bowers@...> writes:

 Richard> A really useful feature would be a cost calculator - something which you
 Richard> could apply to a mute run of a csd file, maybe, or even as a running
 Richard> report (k-rate opcode?). This would be especially useful if the problem
 Richard> re granular synthesis is overcome because of the ability to change
 Richard> parameters in realtime.

Indeed. A cost calculator is high in the to-do list.  In the case of
something like overlaps that can e changed at run time it can only be
an estimate or an average.

==John ffitch


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Atte]

jpff wrote:
> I had a very interesting brain-storming session yesterday in
> preparation for creating a multi-core Csound.

Multi-core Csound sounds very promissing!

--
peace, love & harmony
Atte

http://atte.dk       | http://myspace.com/attejensen
http://anagrammer.dk | http://modlys.dk


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"

[Atte]

Richard Bowers wrote:
> A really useful feature would be a cost calculator

Agreed! Even if the more difficult opcodes are averaged!

--
peace, love & harmony
Atte

http://atte.dk       | http://myspace.com/attejensen
http://anagrammer.dk | http://modlys.dk


Send bugs reports to this list.
To unsubscribe, send email sympa@... with body "unsubscribe csound"