Phil Stone wrote:
Hi Hans,
Thanks for replying. I don't quite understand what you mean by "manually manage". As far as I know, without something like [pd~], there's no way to divide up and assign the Pd audio process to more than one core. Half of the cores on a quad-core are therefore useless to Pd (accounting for the fact that the graphical process gets its own core).
the problem is, that poly-class objects are usually meant for _many_ objects (10+; i'm only repeating here what hans has already said). [pd~] will fork a new thread for each of it's instances. when doing multi-core processing (and this is really the only thing pd~ is good for; e.g .it's not good if you want to have different priorities / asynchronous processing), you usually don't want to create more threads than you have cores. why? performance reasons! if you create e.g. 1000 threads for 1000 instances of [doodle~] on a quad-core machine, your computer will spend more time handling context-switches and the like (that is: the overhead for managing the threads) than doing the actual job. as a rule of thumb, the optimum number of threads is about the number of cores you want to use.
since what is sold to customers as "multi-core" processors usually does not involve more than 4 cores, the "best" (though probably not the most comfortable) way to assign work to the cores from within Pd is doing it "manually"
fmgasdr.# IOhannes