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.