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@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list