[PD] Findings regarding performance

[Roman Haefeli]

Hi João

On Thu, 2011-12-01 at 16:04 +0100, João Pais wrote:
> would it make sense to do a general test patch, where these and more  
> objects could be tested empirically? or, put your patches somewhere, so  
> that other people can work on them, and have a test-repository?

I attached my test setup. It's very naive and it doesn't serve much more
than to compare different classes on a specific setup (Hardware/CPU,
specific Pd version, probably it's even specific to certain compile time
flags).

main.pd loads many (actually 4096) instances of [gate~]. I simply edited
an instance of [gate~] and compared what CPU meter displayed while
main.pd was running. On different computers you probably need to add
more or remove instances of [gate1024~] in order to get meaningful
results.
 
I don't think those patches are worth being included in some test
repository, mainly because the results are so much dependent on the
specific setup. There is no absolute unit (reproducible on any system)
for measuring CPU time, or is there?

> performance considerations aside, I have a reason to use [*~] with line~,  
> instead of switch~: to avoid clicks (in case there is audio when the chain  
> is broken).

I do that as well where applicable. It turns out that [line~] only adds
very little overhead when idling (approximately 0.1ct). Of course, it
uses more while actually ramping. But you can now test that yourself ;-)

Roman



> > Hi all
> >
> > Lately I was asking myself if some of own patching practices regarding
> > performance optimization were justified or based on some wrong beliefs.
> >
> > I often use [*~ ] as on/off signal gates and now started be concerned
> > about using an object that performs a relatively complex task
> > (multiplication of two floating point numbers) for such a simple task. I
> > imagined that an object that either outputs a copy of the input or
> > outputs zeros would be a less expensive on/off signal gate than [*~]. I
> > created an abstraction containing this:
> >
> > [inlet~]     [inlet]
> > |            |
> > |            [switch~ ]
> > |
> > [outlet~]
> >
> > Let's call this abstraction [gate~ ]. It turned out to work as supposed.
> > But is [gate~] really cheaper than [*~ ]? I made a test by connecting
> > lots of [gate~]s to a chain and measure the CPU usage. For simplicity
> > reason, let's just use an invented arbitrary unit for expressing the CPU
> > time (ct) consumed by an object. It turned out that [gate~] uses 0.52ct
> > when it is on and 0.4ct when it is off. But how much does [*~ ] use? No
> > matter whether turned on or off, [*~ ] uses a stable 0.39ct.
> >
> > The relatively complex multiplication is _not_ more expensive than the
> > on/off implementation with [switch~ ]. Even when turned off, the
> > [switch~] approach is still more expensive.
> >
> > But the really interesting finding comes now. [*~ 0] has only 0.2ct!
> > Almost the the ct value of a plain [*~ ] halved! It also doesn't matter
> > what value the argument has. The plain fact of specifying an argument
> > makes [*~ ] a lot cheaper. I also tested [/~ ], [+~ ] and [-~ ] and the
> > same applies for those. They all have 0.39ct without argument and only
> > 0.2ct with an argument specified. Depending on the kind of patch, this
> > allows for quite a significant performance improvement.
> >
> > I also measured the ct of a [*~ ] when a signal wire is connected to the
> > right inlet. It costs exactly as much (0.39ct) as when sending messages
> > to the right inlet of a [*~ ] without argument.
> >
> > My interpretation is that [*~ 0] and [*~ ] are two different objects.
> > The latter always performs a calculation with two signals and implicitly
> > converts a message on the right inlet to a signal, where the former
> > really only deals with messages on the right inlet (and thus is
> > cheaper).
> >
> >
> >
> >
> > On a completely different note, I wanted to know if it costs anything to
> > have signals entering and leaving subpatches and abstractions a lot,
> > respectively if [inlet~] and [outlet~] add some overhead in CPU time. I
> > chained tens of thousands subpatches together and it seems that does not
> > consume any additional CPU time at all. The values for [inlet~ ] and
> > [outlet~] are much below 0.01ct. I haven't tested the cost, when more
> > than one signal wire are going to an [inlet~], though.
> >
> > Roman
> >
> >
> > _______________________________________________
> > Pd-list at iem.at mailing list
> > UNSUBSCRIBE and account-management ->  
> > http://lists.puredata.info/listinfo/pd-list
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: perftest.tar.gz
Type: application/x-compressed-tar
Size: 1279 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20111201/5618f24d/attachment.bin>