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

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@lists.bath.ac.uk 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
>   

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

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