Peter McCulloch

I'm my first MSP external, an analog-style oscillator with built-in polyphony. Everything's going well, and the efficiency is decent (2-4% on a 2.2 Ghz Core Duo) for 9 voices. I'd like to whittle that down if possible; I've gone after the usual suspects (unnecessary calculations, float-to-int, branching).

I've looked through the source code for several people's externals, and I'm curious about the following:

is there a substantial difference between local variables and struct variables? (or indeed any kind of best practice for this?)

I'm my first MSP external, an analog-style oscillator with built-in polyphony.  Everything's going well, and the efficiency is decent (2-4% on a 2.2 Ghz Core Duo) for 9 voices.  I'd like to whittle that down if possible; I've gone after the usual suspects (unnecessary calculations, float-to-int, branching).

I've looked through the source code for several people's externals, and I'm curious about the following:
is there a substantial difference between local variables and struct variables?  (or indeed any kind of best practice for this?)


msp-efficiency-questions

If your variables can be local, then use local variables.

Using struct variables would be memory consuming, and dsp consuming when you access them. And your code would be harder to maintain.

If your variables can be local, then use local variables.
Using struct variables would be memory consuming, and dsp consuming when you access them. And your code would be harder to maintain.


In general, the less you use dereferencing, the more efficiency you get, because each dereferencing requires work.

In fact, I have found that if you use the same value of, say, double *myvar more than a couple of times, it's worth storing the value in a double myvar_value and using this.

Another related thing I found useful is avoiding this

for (i = 0; i < k; i++) dosomethingwith(a[i]);
in favor of
end_a = a + k; for (this_a = a + i; this_a < end_a; this_a++) dosomethingwith(*this_a);

In general, the less you use dereferencing, the more efficiency you get, because each dereferencing requires work. 

Hi guys, thanks for the suggestions! I've got it down to 2% flat now. Ended up that the branching was actually less expensive than the y -= Real2Int(y) (fast version using bit tricks) for the phasor, even with PM.

I discovered Shark yesterday; definitely a useful tool, and a shame they've discontinued it.

since I had heard that C does better with countdowns, though I'm not really sure if this is at all significant.

Hi guys, thanks for the suggestions!  I've got it down to 2% flat now.  Ended up that the branching was actually less expensive than the y -= Real2Int(y) (fast version using bit tricks) for the phasor, even with PM.

I discovered Shark yesterday; definitely a useful tool, and a shame they've discontinued it.  

I've been doing:
short i = 0
(while n--) {
  getElement[i] and do something with it
  i++;
}

since I had heard that C does better with countdowns, though I'm not really sure if this is at all significant.


Yup, and that helped a bit. I'm now trying to figure out the appropriate order of my loops because I can do:

Unfortunately, these both involve while loops.

// Calc value of sample for each oscillator

// Calc increment for each sample step at freq (including PM)

// Integrate and wrap, then do lookups, etc.

Where dsp loop is calculating all of the samples for an oscillator and detune oscillator is calculating the values for any particular oscillator.

One other question: is anyone using SSE? Is this something I should be looking at? (as in, is it widely supported and standardly implemented enough to work on both platforms; Mac is easy, but I don't know if AMD, Atom, etc. chips have the same) I've found some nice code that works with it, but don't know if it's worth going down that alley.

Yup, and that helped a bit.  I'm now trying to figure out the appropriate order of my loops because I can do:
Unfortunately, these both involve while loops.

dspLoop {
      detuneOscillatorLoop() {
            // Calc value of sample for each oscillator
      }
     // inc sample
} 

buildPrototypeOscillator() {
      // Calc increment for each sample step at freq (including PM)
}
detuneOscillator() {
       dspLoop {
             // Integrate and wrap, then do lookups, etc.
       }
}

One other question: is anyone using SSE?  Is this something I should be looking at?  (as in, is it widely supported and standardly implemented enough to work on both platforms; Mac is easy, but I don't know if AMD, Atom, etc. chips have the same)  I've found some nice code that works with it, but don't know if it's worth going down that alley.


are you sure the technique you are using for the wave generation part is appropriate and the algorithm optimized ? You probably will find it more effective to revise and optimize the wave generating algorithm than a for loop.

SSE is widely supported and the gains could be significant especially if you are using 32-bit floating-point types, but it really depends on what type of algorithm you are using. For instance, for a table lookup technique, SSE won't be of great help, I am afraid.

If you are willing to show your code, more help could be given to you.

MSP Efficiency Questions