[PD-dev] Re: [PD] os x performance

[chris clepper]

>hi list,
>more OSX question; on what mostly does the performance level of pd rely?

>  tk

there are a few problems with tcl/tk on osx that are known:

- regions are not updated for drawing properly.  for example if you 
have a patch that takes most of the screen, and put a number box in 
opposite corners of the patch, the entire rectangle region between 
the two boxes will be updated.  this is obviously not very efficient. 
the problematic code has no been isolated for this yet.  until it is 
fixed the best advice is to not use number boxes or sliders that 
update frequently unless for debugging a patch.  for live performance 
they will only limit the amount of CPU available for audio DSP.

- the pixel format that tk/wish uses is not 'mac native' so before 
each updated pixel goes to the screen it is 'swizzled' to the proper 
format.  this is essentially just moving memory around for no reason, 
and coupled with the problem listed above compounds the inefficiency.

>  / compiler

usually, pd is compiled with GCC for all the unix variants and MS 
VC++ on Windows.  GCC 3.x has gotten a lot better at code generation, 
but the PPC version is still not great at optimizing code - it won't 
unroll a loop to save it's life and most of the instruction 
scheduling assumes data is being fed from L1, which happens very 
rarely.  for OSX there are alternatives, namely CodeWarrior and IBM's 
new XLC.  the former is the venerable Mac platform commercial 
compiler, and the latter is now available as a free beta. 
preliminary testing shows XLC to produce better floating point code 
compared to GCC (and XLF slays g77 for FORTRAN), but i quickly ran 
into some trouble building pd with it.  i think some ifdefs will have 
to be rewritten and added to make it compile under XLC.  on the x86 
side, Intel's commercial ICC can produce some extremely fast FP code, 
but is slightly prone to generating erroneous output.

>  / actual code ?

the code in most of pd is fairly generic C implementation of DSP 
algorithms.  nothing really favors any platform, so it's pretty much 
up to the compiler to sort out scheduling and optimization.  since 
the audio portion of pd is single precision floating point it can 
benefit from SIMD coding like SSE and Altivec.  there has been some 
off and on discussion about converting some of the low hanging fruit 
in pd to see what the performance gains are like.  OSX comes with an 
Altivec DSP lib that features FFT and some other common algos which 
may be useful for pd as well.  in general, as long as memory accesses 
aren't out of control, there should be a nice speedup.  if you get 
desperate for some fast PPC DSP routines you can always try 
SuperCollider, which is considered to have some of the finest Mac 
audio code around. ;)

cgc

>amos.
>