[PD] profiling patches and benchmarking platforms for Pd

IOhannes m zmölnig zmoelnig at iem.at
Thu May 14 15:56:47 CEST 2020

On 5/13/20 11:18 PM, Max wrote:
> Hi list,
> I'm sure someone has thought about this before:
> 1. Profiling Pd patches.
> How do you go about if you want to find out which part of your patch is
> using how much of the resources? Is there a better way then looking at
> the CPU meter and deleting some parts?

for messages, your best bet is usually [realtime] to measure the
execution time of a part of the patch (while you have to modify the
patch to do this, you can still keep the entire patch working).
but this works less great if you have multiple event sources.
it also doesn't work at all for DSP.

a more low-level approach would be to run Pd through gprof to collect
call and timing statistics.
the information you gather is on the C-level, so you need to spend some
more brain power to relate that to your patch.
also, you need to recompile Pd (and potential externals).

> 2. Benchmarking platforms for Pd.
> If I want to compare different platforms (armv7 vs. amd64 for example)
> It would be interesting to know the limits of each platform and maybe if
> certain operations are more costly on one platform then on the others
> due to hardware optimizations. I'm imagining a patch running some
> measurements and writing me a textfile out, which I can then compare and
> make nice benchmark graphs from. ;)
> A standardized approach for both would be cool, so that results are
> comparable.

i think it's hard to impossible to find any meaningful benchmark.
which kind of numbers do you expect in your textfile, and how would you
compare them?
e.g. if your PDP-15 is really good at multiplying (so it gets a
multiplications score of 70), how does that compare to your DEC Beta
that only scores 20? how would you determine the multiplications score
required to run your patch?
also, i guess one big limiting factor on devices is the cache size,
which would result in serious degradation if your patch contains more
than a certain number of signal buffers (audio signals that need to
present at the same time), depending on how you inter-connect your
signal objects, the number of signal buffers changes; so you might be
able to run 1000 oscillators on your raspberry when connecting them in
this way, but not if you connect them in that way.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20200514/2426d89d/attachment.sig>

More information about the Pd-list mailing list