Thanks, Oeyvind.

To take matters a bit further, I then (think I) understand that:

1) such "rearrangements" of code, including various numbers of instruments, 
make little to no difference in execution efficiency;
2) small differences are solely due to the numbers and types of arithmetic 
calculations required (and, by extension, any additional code that needs to 
be executed);
3) also implied, I think, is that three instances of a single instrument 
require the same computation as three instruments with similar code 
requiring comparable computation.

Correct?

Art Hunkins

----- Original Message ----- 
From: "Oeyvind Brandtsegg" 
To: 
Sent: Thursday, February 07, 2008 5:26 PM
Subject: [Csnd] Re: More Efficient Execution?


> As you know, the difference is *really* small, however:
>
> As far as I can see, the second version will be a tiny bit faster as
> it uses two multiplications instead of four.
>
> A possible optimization could also be to change
>
> outs (ga1 + ga2) * k1, (ga1 + ga2) * k1
>
> into
>
> aout = (ga1 + ga2) * k1
> outs aout, aout
>
> needing only one multiplication.
>
> Also, why not put both lfo instances in the same instr ? Maybe one
> less instr instantiation will use a tiny bit less CPU.
>
> Oeyvind
>
> 2008/2/7, Art Hunkins :
>> Which of the following *realtime* examples executes more efficiently? My
>> current project uses *many* of the same type of instrument simultaneously
>> (i1/i2), so efficiency will be crucial. And does the answer change if 
>> there
>> are 8+ of instrument type i1/i2?
>>
>> 1)
>> instr 1
>> a1 lfo 1000, 440
>> gk1 ctrl7 1, 10, 0, 1
>> outs a1 * gk1, a1 * gk1
>> endin
>>
>> instr 2
>> a1 lfo 1000, 660
>> outs a1 * gk1, a1 * gk1
>> endin
>>
>> i1 0 60
>> i2 0 60
>>
>> 2)
>> instr 1
>> ga1 lfo 1000, 440
>> endin
>>
>> instr 2
>> ga2 lfo 1000, 660
>> endin
>>
>> instr 3
>> k1 ctrl7 1, 10, 0, 1
>> outs (ga1 + ga2) * k1, (ga1 + ga2) * k1
>> endin
>>
>> i1 0 60
>> i2 0 60
>> i3 0 60
>>
>> TIA,
>>
>> Art Hunkins
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound"
>>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

Hi Art,
Basically you're right. A couple of years ago I asked if there was a  
data on the relative cost of each of the opcodes but I didn't get very  
far. In the old days (late 70s + )  we used to build big instruments  
and because we had a reference of relative cost of each opcode we  
could estimate the load before synth. These days I guess people just  
'suck it and hear.'  It's also harder to get firm figures because  
various HW and OS configs are likely to give different relative results.
I tend to monitor CPU usage using the Mac's Activity Monitor app.   
These opcodes can be useful too:
- cpuprc
- maxalloc  and perhaps
- prealloc

cheers,
David
On 08/02/2008, at 11:36 AM, Art Hunkins wrote:

> Thanks, Oeyvind.
>
> To take matters a bit further, I then (think I) understand that:
>
> 1) such "rearrangements" of code, including various numbers of  
> instruments, make little to no difference in execution efficiency;
> 2) small differences are solely due to the numbers and types of  
> arithmetic calculations required (and, by extension, any additional  
> code that needs to be executed);
> 3) also implied, I think, is that three instances of a single  
> instrument require the same computation as three instruments with  
> similar code requiring comparable computation.
>
> Correct?
>
> Art Hunkins
>
> ----- Original Message ----- From: "Oeyvind Brandtsegg"  >
> To: 
> Sent: Thursday, February 07, 2008 5:26 PM
> Subject: [Csnd] Re: More Efficient Execution?
>
>
>> As you know, the difference is *really* small, however:
>>
>> As far as I can see, the second version will be a tiny bit faster as
>> it uses two multiplications instead of four.
>>
>> A possible optimization could also be to change
>>
>> outs (ga1 + ga2) * k1, (ga1 + ga2) * k1
>>
>> into
>>
>> aout = (ga1 + ga2) * k1
>> outs aout, aout
>>
>> needing only one multiplication.
>>
>> Also, why not put both lfo instances in the same instr ? Maybe one
>> less instr instantiation will use a tiny bit less CPU.
>>
>> Oeyvind
>>
>> 2008/2/7, Art Hunkins :
>>> Which of the following *realtime* examples executes more  
>>> efficiently? My
>>> current project uses *many* of the same type of instrument  
>>> simultaneously
>>> (i1/i2), so efficiency will be crucial. And does the answer change  
>>> if there
>>> are 8+ of instrument type i1/i2?
>>>
>>> 1)
>>> instr 1
>>> a1 lfo 1000, 440
>>> gk1 ctrl7 1, 10, 0, 1
>>> outs a1 * gk1, a1 * gk1
>>> endin
>>>
>>> instr 2
>>> a1 lfo 1000, 660
>>> outs a1 * gk1, a1 * gk1
>>> endin
>>>
>>> i1 0 60
>>> i2 0 60
>>>
>>> 2)
>>> instr 1
>>> ga1 lfo 1000, 440
>>> endin
>>>
>>> instr 2
>>> ga2 lfo 1000, 660
>>> endin
>>>
>>> instr 3
>>> k1 ctrl7 1, 10, 0, 1
>>> outs (ga1 + ga2) * k1, (ga1 + ga2) * k1
>>> endin
>>>
>>> i1 0 60
>>> i2 0 60
>>> i3 0 60
>>>
>>> TIA,
>>>
>>> Art Hunkins
>>>
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>>> "unsubscribe csound"
>>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
>> "unsubscribe csound"
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body  
> "unsubscribe csound"
>

________________________________________________
David Worrall.
- Experimental Polymedia:	www.avatar.com.au
- Education for Financial Independence: www.mindthemarkets.com.au
Australian research affiliations:
- Capital Markets Cooperative Research Centre: www.cmcrc.com
- Sonic Communications Research Group:	creative.canberra.edu.au/scrg