2010/4/6 Tim Blechmann
<tim@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 nehalem
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 smt stuff...
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...
goodnight,
Tim
Question: Then what is the purpose of this "experimental" music?
Answer: No purposes. Sounds.
John Cage
_______________________________________________