Re: [PD] Findings regarding performance

2011-12-02 Thread Mathieu Bouchard
Le 2011-12-02 à 12:41:00, Charles Henry a écrit : You make a good point--I wasn't counting the data transfer that occurs between registers or the way that the compiler breaks out the steps involved, and of which I am mostly ignorant. Ok, well, when you copy, there is a pipeline that goes from

Re: [PD] Findings regarding performance

2011-12-02 Thread Charles Henry
On Thu, Dec 1, 2011 at 4:02 PM, Mathieu Bouchard wrote: > Le 2011-12-01 à 10:39:00, Charles Henry a écrit : > > >> When using [*~ 0], the inlet and outlet are borrowed.  The scalar multiply >> operation is performed in place and no data transfer occurs. > > > What do you call « data transfer » ? m

Re: [PD] Findings regarding performance

2011-12-01 Thread Mathieu Bouchard
Le 2011-12-01 à 10:39:00, Charles Henry a écrit : When using [*~ 0], the inlet and outlet are borrowed. The scalar multiply operation is performed in place and no data transfer occurs. What do you call « data transfer » ? multiplying in place by a constant involves as many reads and writes a

Re: [PD] Findings regarding performance

2011-12-01 Thread Charles Henry
On Thu, Dec 1, 2011 at 11:34 AM, Roman Haefeli wrote: > 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 o

Re: [PD] Findings regarding performance

2011-12-01 Thread 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 set

Re: [PD] Findings regarding performance

2011-12-01 Thread Mathieu Bouchard
Le 2011-12-01 à 17:37:00, Roman Haefeli a écrit : My question ("Is there something more efficient to turn signals on and off than [*~]?") and the things you replied triggered me to do those performance tests. Somehow it is easier for me to deal with stuff that I empirically experience than with

Re: [PD] Findings regarding performance

2011-12-01 Thread Mathieu Bouchard
Le 2011-12-01 à 08:21:00, Jonathan Wilkes a écrit : - Original Message - From: Mathieu Bouchard One is made for blocksizes at least 8, and the other for blocksizes 1,2,4. Ok, so perf8 corresponds to "at least 8".  Thanks. Well, actually it corresponds to "multiples of 8". You can s

Re: [PD] Findings regarding performance

2011-12-01 Thread Charles Henry
On Thu, Dec 1, 2011 at 10:09 AM, Mathieu Bouchard wrote: > Le 2011-12-01 à 15:24:00, Roman Haefeli a écrit : > > >> 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

Re: [PD] Findings regarding performance

2011-12-01 Thread Roman Haefeli
Hi Matju > Are you receiving what I write on IRC ? Not always, I think, but I remember the parts you posted below. My question ("Is there something more efficient to turn signals on and off than [*~]?") and the things you replied triggered me to do those performance tests. Somehow it is easier

Re: [PD] Findings regarding performance

2011-12-01 Thread Jonathan Wilkes
- Original Message - > From: Mathieu Bouchard > To: Jonathan Wilkes > Cc: Roman Haefeli ; PD list > Sent: Thursday, December 1, 2011 10:55 AM > Subject: Re: [PD] Findings regarding performance > > Le 2011-12-01 à 07:00:00, Jonathan Wilkes a écrit : &g

Re: [PD] Findings regarding performance

2011-12-01 Thread Mathieu Bouchard
Le 2011-12-01 à 15:24:00, Roman Haefeli a écrit : 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 o

Re: [PD] Findings regarding performance

2011-12-01 Thread Mathieu Bouchard
Le 2011-12-01 à 07:00:00, Jonathan Wilkes a écrit : After looking at d_arithmetic.c, I'm curiouswhy there is scalartimes_perform and scalartimes_perf8? One is made for blocksizes at least 8, and the other for blocksizes 1,2,4. Perf8 is a kind of explicit loop-unrolling, coded to greatly reduc

Re: [PD] Findings regarding performance

2011-12-01 Thread i go bananas
This repeated buffer only applies to signals sent inside that subpatch, and signals sent out with the [s~ ] object. (i didn't test throw~, but i would guess it's the same) if you just use an [outlet~] object, the buffer is not repeated. see attached test patch if you don't believe me. On Fri,

Re: [PD] Findings regarding performance

2011-12-01 Thread Jaime Oliver
> [inlet~] [inlet] > || > |[switch~ ] > | > [outlet~] Besides clicking problems which you might not care about, If you send a zero to switch~ while there is still audio in the buffer you'll get the buffer repeated over and over. This is why I use both a *~ AND a switc

Re: [PD] Findings regarding performance

2011-12-01 Thread João Pais
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? performance considerations aside, I have a reason to use [*~] with line~, instead of s

Re: [PD] Findings regarding performance

2011-12-01 Thread Jonathan Wilkes
After looking at d_arithmetic.c, I'm curiouswhy there is scalartimes_perform and scalartimes_perf8? -Jonathan - Original Message - > From: Roman Haefeli > To: PD list > Cc: > Sent: Thursday, December 1, 2011 9:24 AM > Subject: [PD] Findings regarding per

[PD] Findings regarding performance

2011-12-01 Thread Roman Haefeli
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