[PD] implications of pd~ for 'poly' objects

[IOhannes m zmoelnig]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3636 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20090909/e073ed38/attachment.bin>