Phase vocoder: polar vs Cartesian efficiency

    Nov 06 2011 | 5:15 pm
    In the Dudas/Lippe phase vocoder tutorials, as well as on this forum, I find claims that an implementation using Cartesian math is much more efficient than working in polar coordinates. It makes sense that it would be, but when I compare the Cartesian and polar versions of the tutorial patches, I don't see any noticeable difference in CPU utilization. Am I doing something wrong, or is arctan not the bottleneck it used to be?
    I'm using OS X 10.6 and Max 5.1.8, for what it's worth. Incidentally, in my own C++ code, I can't see a difference either. Am I alone in not seeing the speed advantage of a Cartesian pvoc?

    • Nov 06 2011 | 8:18 pm
      I see the same here with the tutorial patches.
      It's possible that the trig is not significant anymore in terms of the patch as a whole. Also, the cartesian version involves a sqrt and a divide, plus a lot more basic arithmetic which is an increase of cost. As always with optimisations, the cost of various parts of an algorithm can change over time and the balance can shift.
      Looks this might be one such case. For me pfft~ is normally the bottleneck with FFT processes (or more correctly fftin~ / fftout~). FWIW I find the best way for dev stuff to judge costs on mac is to Shark it - in this kind of cae where you want to know the cost of various objects it can work for patches too...
    • Nov 06 2011 | 9:01 pm
      Thanks, Alex. That makes sense, esp. with the overhead of additional MSP objects for the Cartesian version. Though I did see a similar situation in my C++ code. I just wondered if I was missing something.