sin function…

Feb 5, 2007 at 8:21pm

sin function…

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.

#30128
Feb 5, 2007 at 9:23pm

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
> 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.

—-
Steven M. Miller

Home < http://pubweb.csf.edu/~smill>
SFIFEM <
http://sfifem.csf.edu>
Atrium Sound Space <
http://atrium.csf.edu>
OVOS <
http://pubweb.csf.edu/~smill/ovos.html>

#95633
Feb 6, 2007 at 10:27am

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
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.

– P.

(*) 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

#95634
Feb 7, 2007 at 4:53pm

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.

#95635

You must be logged in to reply to this topic.