[PD] Maximizing Efficiency

Mathieu Bouchard matju at sympatico.ca
Sat Jan 25 22:18:42 CET 2003

On Sat, 25 Jan 2003, marius schebella wrote:

> very good point, would it be possible to have a standardized
> measure-procedure for objects, and write down the cost of cpu-time of
> all (or some important) objects in a list? i think it is not difficult
> to measure,

For whomever may be interested in implementing this in PD:

GridFlow used to support this feature. I called it runtime profiling
(because you get the results while the program runs, and you can reset
the timers, and so on). Classic profiling is more like: you'd run PD once,
and get a report after you shut it down.

There are difficulties with making the measures: all calls into any inlet
and out of any outlet must be intercepted, and the clock must be looked at
each time. You run into the issue that making the measures at all has an
influence on the performance of your patch. To minimize that, there are
three tricks i've found:

1. use a different clock. time(), gettimeofday() are slow compared to
RDTSC, a Pentium opcode, because the latter performs no context switches.
This is not portable, but I hear there are similar opcode in other modern
machine languages.

2. make big operations. measures will be better if less time is spent
going in and out of procedures. GridFlow happens to be following this
since its first real version (0.2.0). Whenever it can, operations are
vectorized on ~4000-byte chunks. However, this does not happen naturally
in PD, on average: in the DSP, ~128-byte chunks are used, whereas ~4-byte
chunks are used in the message system. Similarly, GridFlow may operate on
small datasets (e.g. scalars!) if you tell it so, and will then have no
choice but to use chunks of that size.

3. use statistical methods. that's a completely different way to profile;
you get fuzzier values in a sense, but the measuring has less of an effect
on the measures, so the net result may be more accurate. It could also be
less invasive on the code; however, getting to know which object is
currently processing is black magic unless you get some cooperation from
the execution engine. That cooperation might be like: all calls are
intercepted, but the intercepting doesn't read the clock, it just takes
note of which object is the current one, and puts that in a global
variable (which is then read by the profiler).

Mathieu Bouchard                       http://artengine.ca/matju

More information about the Pd-list mailing list