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

Phil Stone pkstone at ucdavis.edu
Wed Sep 9 17:22:40 CEST 2009


Thanks for clarifying that, Hans, and for pointing out the issue with 
threads, IOhannes.  One shouldn't be profligate with [pd~]s, strewing 
them all about and expecting performance gains -- therefore, one [pd~] 
per voice instance in a [polypoly] patch is probably not a good idea 
until we have 64-core CPUs as a regular thing! :-).

However, with judicious use, [pd~] seems like it will allow Pd to scale 
to future processor design, and that's a good thing.

Thanks again,

Phil


Hans-Christoph Steiner wrote:
>
> [snip]  As for manually managing pd~, I mean just manually creating as 
> many pd~ instances as you have cores.
>
> .hc
>>
>>
>> IOhannes m zmoelnig wrote:
>>> 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
>>> ------------------------------------------------------------------------ 
>>>
>>> _______________________________________________
>>> Pd-list at iem.at mailing list
>>> UNSUBSCRIBE and account-management -> 
>>> http://lists.puredata.info/listinfo/pd-list
>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management -> 
>> http://lists.puredata.info/listinfo/pd-list
>
>
>
> ---------------------------------------------------------------------------- 
>
>
> I have the audacity to believe that peoples everywhere can have three 
> meals a day for their bodies, education and culture for their minds, 
> and dignity, equality and freedom for their spirits.      - Martin 
> Luther King, Jr.
>
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>





More information about the Pd-list mailing list