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.

gfmdsra IOhannes