grimepoch

I had a performance question. I have some rather complex calculations using a bunch of sin/cos calls in expr objects. I know there are only 128 sin/cos values that I need. Is it faster to create a lookup table and just look up the results instead.

Also, if this is a good idea, do I just create a set of helper functions to create the table, then get rid of them in my patch (or disable them I guess since if they are not being used, they are no going to be using up space.

I had a performance question.  I have some rather complex calculations using a bunch of sin/cos calls in expr objects.  I know there are only 128 sin/cos values that I need.  Is it faster to create a lookup table and just look up the results instead.

Also, if this is a good idea, do I just create a set of helper functions to create the table, then get rid of them in my patch (or disable them I guess since if they are not being used, they are no going to be using up space.


sin-function

On Feb 5, 2007, at 1:21 PM, Rick Burnett wrote:

> I had a performance question. I have some rather complex 

> calculations using a bunch of sin/cos calls in expr objects. I 

> know there are only 128 sin/cos values that I need. Is it faster 

> to create a lookup table and just look up the results instead.

From a historical basis, the relative economy of table lookup vs. 

direct evaluation of the waveform function was a big issue in earlier 

days. Not sure of there's still as much emphasis on this with the 

speed of today's processors. Perhaps someone more 'in the know' about 

MaxMSP's internal functions might have some particular insight...

> Also, if this is a good idea, do I just create a set of helper 

> functions to create the table, then get rid of them in my patch (or 

> disable them I guess since if they are not being used, they are no 

You could write wavetable functions as separate patches - no need to 

integrate them into the patch that uses the resulting tables 

themselves. As a possible place to start, info on the various Csound 

GEN routines is available online in a variety of places. You can also 

find wavetable gen functions in some 3rd party MaxMSP object 

libraries (Percolate, for example has some).

Personally, I'd love it if some C programmer out there created a 

whole library of objects to instantiate all the Csound GEN routines 

>
> I had a performance question.  I have some rather complex  
> calculations using a bunch of sin/cos calls in expr objects.  I  
> know there are only 128 sin/cos values that I need.  Is it faster  
> to create a lookup table and just look up the results instead.

 From a historical basis, the relative economy of table lookup vs.  
direct evaluation of the waveform function was a big issue in earlier  
days. Not sure of there's still as much emphasis on this with the  
speed of today's processors. Perhaps someone more 'in the know' about  
MaxMSP's internal functions might have some particular insight...

>
> Also, if this is a good idea, do I just create a set of helper  
> functions to create the table, then get rid of them in my patch (or  
> disable them I guess since if they are not being used, they are no  
> going to be using up space.

You could write wavetable functions as separate patches - no need to  
integrate them into the patch that uses the resulting tables  
themselves. As a possible place to start, info on the various Csound  
GEN routines is available online in a variety of places. You can also  
find wavetable gen functions in some 3rd party MaxMSP object  
libraries (Percolate, for example has some).

Personally, I'd love it if some C programmer out there created a  
whole library of objects to instantiate all the Csound GEN routines  
in MaxMSP.

On 5-Feb-2007, at 22:23, Steven Miller wrote:

> On Feb 5, 2007, at 1:21 PM, Rick Burnett wrote:

>> I had a performance question. I have some rather complex 

>> calculations using a bunch of sin/cos calls in expr objects. I 

>> know there are only 128 sin/cos values that I need. Is it faster 

>> to create a lookup table and just look up the results instead.

Are you experiencing a performance bottleneck?

If not, I wouldn't worry much about it. At least as long as you have 

no indication that there are performance problems.

If you really only have 128 values and nothing in between, a lookup 

table is a logical design approach. But the Nr. 1 engineering rule 

is: if it ain't broke, don't fix it. Which brings us back to my first 

> From a historical basis, the relative economy of table lookup vs. 

> direct evaluation of the waveform function was a big issue in 

> earlier days. Not sure of there's still as much emphasis on this 

> with the speed of today's processors. Perhaps someone more 'in the 

> know' about MaxMSP's internal functions might have some particular 

There was a discussion here quite a while ago as to whether modern 

processors, which could evaluate a Taylor series just using FP 

registers, might actually be more efficient in trig using direct 

calculation rather than table lookup, which (almost) inevitably 

requires hitting RAM. OTOH, processor caches have also gotten large 

enough to hold a reasonably large lookup table.

At the time, someone (perhaps undersigned) suggested that somebody 

oughta write a test app to compare performance. Personally, I suspect 

table lookup will still win out. But who knows? I've only got gut 

feeling to go on and nobody's taken on the challenge.

>> Also, if this is a good idea, do I just create a set of helper 

>> functions to create the table, then get rid of them in my patch 

>> (or disable them I guess since if they are not being used, they 

A common Max technique in this case would be something like loadbang- 

>uzi->expr->peek~. The memory overhead is nothing to lose sleep 

over, but it will slow down patch load time by some fraction of a 

second. The suggestion below is worth considering.

Again, if your patch is performing OK, I would advise you not to muck 

> You could write wavetable functions as separate patches - no need 

> to integrate them into the patch that uses the resulting tables 

> themselves. As a possible place to start, info on the various 

> Csound GEN routines is available online in a variety of places. You 

> can also find wavetable gen functions in some 3rd party MaxMSP 

> object libraries (Percolate, for example has some).

> Personally, I'd love it if some C programmer out there created a 

> whole library of objects to instantiate all the Csound GEN routines 

I had the impression that any GENxx routines *not* provided by 

Percolate(*) were easily implementable by factory Max objects. But I 

may be missing some. Have you tried writing to Luke Dubois to ask if 

he'd consider adding whatever you feel is missing?

You might also have an interesting discussion about what constitutes 

(*) Sorry Luke, I can never remember the 'correct' capitalization. 

And I'm more particular about orthography than a lot of people.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

On 5-Feb-2007, at 22:23, Steven Miller wrote:
> On Feb 5, 2007, at 1:21 PM, Rick Burnett wrote:
>> I had a performance question.  I have some rather complex  
>> calculations using a bunch of sin/cos calls in expr objects.  I  
>> know there are only 128 sin/cos values that I need.  Is it faster  
>> to create a lookup table and just look up the results instead.

If not, I wouldn't worry much about it. At least as long as you have  
no indication that there are performance problems.

If you really only have 128 values and nothing in between, a lookup  
table is a logical design approach. But the Nr. 1 engineering rule  
is: if it ain't broke, don't fix it. Which brings us back to my first  
question.

> From a historical basis, the relative economy of table lookup vs.  
> direct evaluation of the waveform function was a big issue in  
> earlier days. Not sure of there's still as much emphasis on this  
> with the speed of today's processors. Perhaps someone more 'in the  
> know' about MaxMSP's internal functions might have some particular  
> insight...

There was a discussion here quite a while ago as to whether modern  
processors, which could evaluate a Taylor series just using FP  
registers, might actually be more efficient in trig using direct  
calculation rather than table lookup, which (almost) inevitably  
requires hitting RAM. OTOH, processor caches have also gotten large  
enough to hold a reasonably large lookup table.

At the time, someone (perhaps undersigned) suggested that somebody  
oughta write a test app to compare performance. Personally, I suspect  
table lookup will still win out. But who knows? I've only got gut  
feeling to go on and nobody's taken on the challenge.

>> Also, if this is a good idea, do I just create a set of helper  
>> functions to create the table, then get rid of them in my patch  
>> (or disable them I guess since if they are not being used, they  
>> are no going to be using up space.

A common Max technique in this case would be something like loadbang- 
 >uzi->expr->peek~. The memory overhead is nothing to lose sleep  
over, but it will slow down patch load time by some fraction of a  
second. The suggestion below is worth considering.

Again, if your patch is performing OK, I would advise you not to muck  
with it.

> You could write wavetable functions as separate patches - no need  
> to integrate them into the patch that uses the resulting tables  
> themselves. As a possible place to start, info on the various  
> Csound GEN routines is available online in a variety of places. You  
> can also find wavetable gen functions in some 3rd party MaxMSP  
> object libraries (Percolate, for example has some).
>
> Personally, I'd love it if some C programmer out there created a  
> whole library of objects to instantiate all the Csound GEN routines  
> in MaxMSP.

I had the impression that any GENxx routines *not* provided by  
Percolate(*) were easily implementable by factory Max objects. But I  
may be missing some. Have you tried writing to Luke Dubois to ask if  
he'd consider adding whatever you feel is missing?

You might also have an interesting discussion about what constitutes  
the 'canonical' set of GENxx functions.

(*) Sorry Luke, I can never remember the 'correct' capitalization.  
And I'm more particular about orthography than a lot of people.

--------------    http://www.bek.no/~pcastine/Litter/    -------------
Peter Castine             +--> Litter Power & Litter Bundle for Jitter
                                Universal Binaries on the way
iCE:  Sequencing,  Recording &
       Interface  Building  for                   |home    | chez nous|
       Max/MSP   Extremely cool                   |bei uns |  i nostri|
       http://www.dspaudio.com/                   http://www.castine.de

Thanks for the responses. I think the problem I am seeing is just the way I am updating my UI, so I am rethinking how I have implemented it. Even with a table I think it would be slow since I am doing a lot of calculations that I could re-use if I rethink my design.

Thanks for the responses.  I think the problem I am seeing is just the way I am updating my UI, so I am rethinking how I have implemented it.  Even with a table I think it would be slow since I am doing a lot of calculations that I could re-use if I rethink my design.


sin function...