## Re: [Cs-dev] How long does an opcode take

 Re: [Cs-dev] How long does an opcode take From: jpff - 2008-07-30 08:58:52 ```I will try to explain the measurements and the purposes to which they could be put. In order that an opcode OP is to be played for T seconds it will need to be initialised (i-rate) and then it is performed. The performance function will be called T*kr times. Each of these calls has a fixed cost and a cost that is proportional to ksmps. So the cost of OP for T secs is A + T*kr*(B*ksmps + C) As ksmps*kr is sr you can view this as A + T*sr*B + T*kr*C A is immutable, B is the cost per sample and C is the cost of using a kontrol rate. The measurements were done on an i386 using valgrind and similar tools, using Trapped and Hans Mikelson's Teknobubble. Clearly the figures average the effect of different parameters, and there are some oddities that suggest that the tools need a little tweak, So uses: for rt performance it tells you the value of the kr reduction against quality. When there are more opcodes measured it should inform the choice of detailed methods. For parallelism it is essential that the granularity of the tasks is considered, and over the years I have played with parallelism I have seems significant slowdowns as the small granularity messes up the overhead cost of task switch or distribution. I hope this clarifies things a little. I am afraid that at heart I am a mathematician so formulae are clearer than words in these cases. Happy to answer questions take requests for particular opcodes to be measured or whatever improves csound. Below is my current data set ==John ffitch ------------------------------------------------------------------------ A B C (missing values are zero) !=.i: 13 !=.k: 0 0 13 *.ak: 0 6 15 *.ka: 0 6 15 *.kk: 0 0 9 +.aa: 0 6 16 +.kk: 0 0 9 /.ak: 0 6 20 /.kk: 0 0 9 =.i 7 =.k: 0 0 7 =.a: 0 1 15 -.kk: 0 0 9 grain: 497 917.921440 79475.154651 arand: 52 -0.351226 188.512264 balance: 38 2.351111 274.488889 butterbp: 20 30 71 butterhi: 19 30.000387 35 butterlp: 19 29.005359 45.478359 buzz: 75 -0.639775 430.385596 cpspch: 106.368056 delay: 4097 -0.340018 157.403009 exp.i: 19.412868 exp.k: 0 0 19.412868 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 init: 0 4 12 int.i: 67 integrate: 13 5 17 kcgoto: 0 0.000022 8.758767 kgoto: 0 0 7 line.k: 20 0.000762 8.992379 linen.k: 62 0.000004 20.650515 linseg.k: 266.971564 0.000559 29.994448 nlfilt: 1068.813496 52.985889 100.158886 octpch.i: 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 =.r: 2 reinit: 0 0 16335.400000 reson: 39 13.002546 99.545002 reverb: 6963.481481 77.038957 157.999993 rms: 32 10 21 sqrt.i: 8 sqrt.k: 0 0 8 table.a: 93 23.062626 43.997796 table.k: 93 0 45 tablei.k: 93 0 61 timout: 40 -0.002915 15.235836 upsamp: 0 4 12 vdelay: 2073.886076 53.572573 69.049966 zacl: 14 51 54 zar: 14 1 41 zaw: 14 1.000018 38.998197 zkcl: 14 0 101 zkr: 14 0 32 zkw: 14 0 31.999964 **end** ```

 [Cs-dev] How long does an opcode take From: jpff - 2008-07-29 13:56:17 ```Following on from an earlier message, I have now slightly refined my model. For an opcode I am assuming that there is a fix initialisation A, and a time that is obeyed every k-cycle, B*k+C where k is the ksmps. The table below is of A B and C for the opcodes used in Trapped which is my basic test. In the case of i-rate opcodes I have omitted B and C. You will see some oddities mike a few negative numbers, which I have not understood yet, but I think the larger view is correct. Counts are in instructions on a i386, and that may not scale exactly to time. ==John ffitch ------------------------------------------------------------------------ *.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 ```
 Re: [Cs-dev] How long does an opcode take From: Dr. Richard Boulanger - 2008-07-29 19:24:21 ```John, This is interesting. Could you explain a bit more about how to interpret this data - I would love to share it with my students in class tomorrow and give them a clear and accurate sense of the computing that is involved in rendering the piece. Rick On Jul 29, 2008, at 9:56 AM, jpff wrote: > Following on from an earlier message, I have now slightly refined my > model. For an opcode I am assuming that there is a fix initialisation > A, and a time that is obeyed every k-cycle, B*k+C where k is the > ksmps. > The table below is of A B and C for the opcodes used in Trapped > which is my basic test. In the case of i-rate opcodes I have omitted > B and C. > You will see some oddities mike a few negative numbers, which I have > not understood yet, but I think the larger view is correct. Counts > are in instructions on a i386, and that may not scale exactly to time. > ==John ffitch > ---------------------------------------------------------------------- > -- > *.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 > > ---------------------------------------------------------------------- > --- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Csound-devel mailing list > Csound-devel@... > https://lists.sourceforge.net/lists/listinfo/csound-devel ```
 Re: [Cs-dev] How long does an opcode take From: Oeyvind Brandtsegg - 2008-07-29 22:26:33 ```This is interesting, also as an indicator to the performance gain in increasing ksmp, relative to what opcodes are used. If I understand the data correctly, if B is (relatively) high and C is low, the performance gain in increasing ksmps is less than if B is low and C is high. Or... do I completely misunderstand the meaning of the data ? Maybe the difference is insiginficant in practice. Oeyvind 2008/7/29, jpff : > Following on from an earlier message, I have now slightly refined my > model. For an opcode I am assuming that there is a fix initialisation > A, and a time that is obeyed every k-cycle, B*k+C where k is the > ksmps. > The table below is of A B and C for the opcodes used in Trapped > which is my basic test. In the case of i-rate opcodes I have omitted > B and C. > You will see some oddities mike a few negative numbers, which I have > not understood yet, but I think the larger view is correct. Counts > are in instructions on a i386, and that may not scale exactly to time. > ==John ffitch > ------------------------------------------------------------------------ > *.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 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Csound-devel mailing list > Csound-devel@... > https://lists.sourceforge.net/lists/listinfo/csound-devel > ```
 Re: [Cs-dev] How long does an opcode take From: jpff - 2008-07-30 08:58:52 ```I will try to explain the measurements and the purposes to which they could be put. In order that an opcode OP is to be played for T seconds it will need to be initialised (i-rate) and then it is performed. The performance function will be called T*kr times. Each of these calls has a fixed cost and a cost that is proportional to ksmps. So the cost of OP for T secs is A + T*kr*(B*ksmps + C) As ksmps*kr is sr you can view this as A + T*sr*B + T*kr*C A is immutable, B is the cost per sample and C is the cost of using a kontrol rate. The measurements were done on an i386 using valgrind and similar tools, using Trapped and Hans Mikelson's Teknobubble. Clearly the figures average the effect of different parameters, and there are some oddities that suggest that the tools need a little tweak, So uses: for rt performance it tells you the value of the kr reduction against quality. When there are more opcodes measured it should inform the choice of detailed methods. For parallelism it is essential that the granularity of the tasks is considered, and over the years I have played with parallelism I have seems significant slowdowns as the small granularity messes up the overhead cost of task switch or distribution. I hope this clarifies things a little. I am afraid that at heart I am a mathematician so formulae are clearer than words in these cases. Happy to answer questions take requests for particular opcodes to be measured or whatever improves csound. Below is my current data set ==John ffitch ------------------------------------------------------------------------ A B C (missing values are zero) !=.i: 13 !=.k: 0 0 13 *.ak: 0 6 15 *.ka: 0 6 15 *.kk: 0 0 9 +.aa: 0 6 16 +.kk: 0 0 9 /.ak: 0 6 20 /.kk: 0 0 9 =.i 7 =.k: 0 0 7 =.a: 0 1 15 -.kk: 0 0 9 grain: 497 917.921440 79475.154651 arand: 52 -0.351226 188.512264 balance: 38 2.351111 274.488889 butterbp: 20 30 71 butterhi: 19 30.000387 35 butterlp: 19 29.005359 45.478359 buzz: 75 -0.639775 430.385596 cpspch: 106.368056 delay: 4097 -0.340018 157.403009 exp.i: 19.412868 exp.k: 0 0 19.412868 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 init: 0 4 12 int.i: 67 integrate: 13 5 17 kcgoto: 0 0.000022 8.758767 kgoto: 0 0 7 line.k: 20 0.000762 8.992379 linen.k: 62 0.000004 20.650515 linseg.k: 266.971564 0.000559 29.994448 nlfilt: 1068.813496 52.985889 100.158886 octpch.i: 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 =.r: 2 reinit: 0 0 16335.400000 reson: 39 13.002546 99.545002 reverb: 6963.481481 77.038957 157.999993 rms: 32 10 21 sqrt.i: 8 sqrt.k: 0 0 8 table.a: 93 23.062626 43.997796 table.k: 93 0 45 tablei.k: 93 0 61 timout: 40 -0.002915 15.235836 upsamp: 0 4 12 vdelay: 2073.886076 53.572573 69.049966 zacl: 14 51 54 zar: 14 1 41 zaw: 14 1.000018 38.998197 zkcl: 14 0 101 zkr: 14 0 32 zkw: 14 0 31.999964 **end** ```
 Re: [Cs-dev] How long does an opcode take From: Oeyvind Brandtsegg - 2008-07-30 09:38:31 ```Thanks John, this seems very clear. Oeyvind 2008/7/30, jpff : > I will try to explain the measurements and the purposes to which they > could be put. > > In order that an opcode OP is to be played for T seconds it will need > to be initialised (i-rate) and then it is performed. The performance > function will be called T*kr times. Each of these calls has a fixed > cost and a cost that is proportional to ksmps. > > So the cost of OP for T secs is > A + T*kr*(B*ksmps + C) > > As ksmps*kr is sr you can view this as > > A + T*sr*B + T*kr*C > > A is immutable, B is the cost per sample and C is the cost of using a > kontrol rate. > > The measurements were done on an i386 using valgrind and similar > tools, using Trapped and Hans Mikelson's Teknobubble. Clearly the > figures average the effect of different parameters, and there are some > oddities that suggest that the tools need a little tweak, > > So uses: for rt performance it tells you the value of the kr reduction > against quality. When there are more opcodes measured it should inform > the choice of detailed methods. > > For parallelism it is essential that the granularity of the tasks is > considered, and over the years I have played with parallelism I have > seems significant slowdowns as the small granularity messes up the > overhead cost of task switch or distribution. > > I hope this clarifies things a little. I am afraid that at heart I am > a mathematician so formulae are clearer than words in these cases. > Happy to answer questions take requests for particular opcodes to be > measured or whatever improves csound. > > Below is my current data set > ==John ffitch > ------------------------------------------------------------------------ > A B C (missing values are zero) > !=.i: 13 > !=.k: 0 0 13 > *.ak: 0 6 15 > *.ka: 0 6 15 > *.kk: 0 0 9 > +.aa: 0 6 16 > +.kk: 0 0 9 > /.ak: 0 6 20 > /.kk: 0 0 9 > =.i 7 > =.k: 0 0 7 > =.a: 0 1 15 > -.kk: 0 0 9 > grain: 497 917.921440 79475.154651 > arand: 52 -0.351226 188.512264 > balance: 38 2.351111 274.488889 > butterbp: 20 30 71 > butterhi: 19 30.000387 35 > butterlp: 19 29.005359 45.478359 > buzz: 75 -0.639775 430.385596 > cpspch: 106.368056 > delay: 4097 -0.340018 157.403009 > exp.i: 19.412868 > exp.k: 0 0 19.412868 > 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 > init: 0 4 12 > int.i: 67 > integrate: 13 5 17 > kcgoto: 0 0.000022 8.758767 > kgoto: 0 0 7 > line.k: 20 0.000762 8.992379 > linen.k: 62 0.000004 20.650515 > linseg.k: 266.971564 0.000559 29.994448 > nlfilt: 1068.813496 52.985889 100.158886 > octpch.i: 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 > =.r: 2 > reinit: 0 0 16335.400000 > reson: 39 13.002546 99.545002 > reverb: 6963.481481 77.038957 157.999993 > rms: 32 10 21 > sqrt.i: 8 > sqrt.k: 0 0 8 > table.a: 93 23.062626 43.997796 > table.k: 93 0 45 > tablei.k: 93 0 61 > timout: 40 -0.002915 15.235836 > upsamp: 0 4 12 > vdelay: 2073.886076 53.572573 69.049966 > zacl: 14 51 54 > zar: 14 1 41 > zaw: 14 1.000018 38.998197 > zkcl: 14 0 101 > zkr: 14 0 32 > zkw: 14 0 31.999964 > **end** > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Csound-devel mailing list > Csound-devel@... > https://lists.sourceforge.net/lists/listinfo/csound-devel > ```
 Re: [Cs-dev] How long does an opcode take From: Dr. Richard Boulanger - 2008-07-30 10:26:52 ```Thanks John.... this is really helpful and I can't wait to present this email today - and play the piece for the class. It will be an eye opener for them (as it is for me) Rick On Jul 30, 2008, at 4:58 AM, jpff wrote: > I will try to explain the measurements and the purposes to which they > could be put. > > In order that an opcode OP is to be played for T seconds it will need > to be initialised (i-rate) and then it is performed. The performance > function will be called T*kr times. Each of these calls has a fixed > cost and a cost that is proportional to ksmps. > > So the cost of OP for T secs is > A + T*kr*(B*ksmps + C) > > As ksmps*kr is sr you can view this as > > A + T*sr*B + T*kr*C > > A is immutable, B is the cost per sample and C is the cost of using a > kontrol rate. > > The measurements were done on an i386 using valgrind and similar > tools, using Trapped and Hans Mikelson's Teknobubble. Clearly the > figures average the effect of different parameters, and there are some > oddities that suggest that the tools need a little tweak, > > So uses: for rt performance it tells you the value of the kr reduction > against quality. When there are more opcodes measured it should > inform > the choice of detailed methods. > > For parallelism it is essential that the granularity of the tasks is > considered, and over the years I have played with parallelism I have > seems significant slowdowns as the small granularity messes up the > overhead cost of task switch or distribution. > > I hope this clarifies things a little. I am afraid that at heart I am > a mathematician so formulae are clearer than words in these cases. > Happy to answer questions take requests for particular opcodes to be > measured or whatever improves csound. > > Below is my current data set > ==John ffitch > ---------------------------------------------------------------------- > -- > A B C (missing values are zero) > !=.i: 13 > !=.k: 0 0 13 > *.ak: 0 6 15 > *.ka: 0 6 15 > *.kk: 0 0 9 > +.aa: 0 6 16 > +.kk: 0 0 9 > /.ak: 0 6 20 > /.kk: 0 0 9 > =.i 7 > =.k: 0 0 7 > =.a: 0 1 15 > -.kk: 0 0 9 > grain: 497 917.921440 79475.154651 > arand: 52 -0.351226 188.512264 > balance: 38 2.351111 274.488889 > butterbp: 20 30 71 > butterhi: 19 30.000387 35 > butterlp: 19 29.005359 45.478359 > buzz: 75 -0.639775 430.385596 > cpspch: 106.368056 > delay: 4097 -0.340018 157.403009 > exp.i: 19.412868 > exp.k: 0 0 19.412868 > 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 > init: 0 4 12 > int.i: 67 > integrate: 13 5 17 > kcgoto: 0 0.000022 8.758767 > kgoto: 0 0 7 > line.k: 20 0.000762 8.992379 > linen.k: 62 0.000004 20.650515 > linseg.k: 266.971564 0.000559 29.994448 > nlfilt: 1068.813496 52.985889 100.158886 > octpch.i: 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 > =.r: 2 > reinit: 0 0 16335.400000 > reson: 39 13.002546 99.545002 > reverb: 6963.481481 77.038957 157.999993 > rms: 32 10 21 > sqrt.i: 8 > sqrt.k: 0 0 8 > table.a: 93 23.062626 43.997796 > table.k: 93 0 45 > tablei.k: 93 0 61 > timout: 40 -0.002915 15.235836 > upsamp: 0 4 12 > vdelay: 2073.886076 53.572573 69.049966 > zacl: 14 51 54 > zar: 14 1 41 > zaw: 14 1.000018 38.998197 > zkcl: 14 0 101 > zkr: 14 0 32 > zkw: 14 0 31.999964 > **end** > > ---------------------------------------------------------------------- > --- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Csound-devel mailing list > Csound-devel@... > https://lists.sourceforge.net/lists/listinfo/csound-devel ```