[PD] pd and multi-core processors
timvets at gmail.com
Wed Apr 7 02:02:29 CEST 2010
2010/4/6 Tim Blechmann <tim at klingt.org>
> > With my patch open i get these values (average):
> > cpu1 60% cpu2 60% cpu3 11% cpu4 2%
> > Then, when I open a pd~ patch:
> > cpu1 80% cpu2 80% cpu3 40% cpu4 3%
> the average cpu load won't tell you a lot, since the cpu speed is usually
> not constant, but may be modulated (adding some latency hotspots). in
> general, i'd recommend to disable frequency scaling, turbo mode (for
> cpus) and smt, since it may confuse numbers and can increase the thread
> wakeup latency significantly, if you want to use a machine for low-latency
> real-time audio applications.
thanks for the tip. I have no idea how to do that though.
I admit not having searched for very long (it's late), but i couldn't find
an easy peasy how-to disable frequency scaling, or about that turbo mode and
maybe you (or someone else) can explain this in a bit more detail?
> > so, still plenty of overhead on the 4th core, but it doesn't seem to be
> > used.
> from my understanding, you should split your path into 4 pieces of equal
> load, using 3 pd~ objects, if you want to optimize it for a quad-core cpu.
hmm, if I try to load one patch into a pd~ object I get garbled sound, even
without switch~ing it on.
Would you think if I split off more of my main patch into more pd~ objects
it would improve ?
The fact that using pd~ results in more hickups than a normal abstraction
leads me to suspect something else is wrong...
> tim at klingt.org
> Question: Then what is the purpose of this "experimental" music?
> Answer: No purposes. Sounds.
> John Cage
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list