[PD] list vs. symbol array [was: Re: Licensing issues]

[Dan Wilcox]

On Nov 7, 2012, at 8:49 PM, pd-list-request at iem.at wrote:

> From: Jonathan Wilkes <jancsika at yahoo.com>
> Subject: Re: [PD] list vs. symbol array [was: Re: Licensing issues]
> Date: November 7, 2012 8:45:49 PM EST
> To: Frank Barknecht <fbar at footils.org>, "pd-list at iem.at" <pd-list at iem.at>
> Reply-To: Jonathan Wilkes <jancsika at yahoo.com>
> 
> 
> ----- Original Message -----
> 
>> From: Frank Barknecht <fbar at footils.org>
>> To: "pd-list at iem.at" <pd-list at iem.at>
>> Cc: 
>> Sent: Tuesday, November 6, 2012 6:19 AM
>> Subject: [PD] list vs. symbol array [was: Re:  Licensing issues]
>> 
>> I'm pretty sure, the patch at that time didn't either. The main problem 
>> then
>> was the high frequency with which lookups had to happen. As a special election
>> day service I have written a benchmark showing this situation. On my machine
>> the symbolarray uses about 16 percent CPU at the "metro" period of 
>> 0.01 ms
>> while list lookup uses 24. Now 0.01 ms may sound like a tempo you won't
>> encounter in real music, but that's wrong: In chords you play many notes at 
>> the
>> same time, the "period" then is a very fast 0 ms. This can generate 
>> CPU usage
>> spikes on slow devices if the lookup is too slow - at least that's my
>> explanation for why the symbolarray was able to fix the patch.
> 
> [symbolarray] does indeed take about half as much cpu as using the message
> box.  It also takes exactly the same cpu as [makefilename %d-tab] which is
> much simpler and doesn't require an abstraction.  But maybe you needed 
> those specific names for the tables for some reason...
> 
> A lot of these Pd vanilla prototypes suffer from already being at the very edge
> of what can be developed with the prototype.  You can't easily[1] add a sort method,
> for example, nor can you extend the design to allow each element to be either a
> symbol or float without adding two fields to the template struct and a conditional
> that would impact the performance gain you get from using an array in the first
> place.  Not to mention the near-complete lack of operators for symbols which is
> why I call it an array of Pet Rocks in this case.
> 
> -Jonathan

I didn't mean to bring up an externals vs vanilla debate. We obviously use what's best for the situation. I'm choosing to work more in vanilla land because I simply can't include some externals in my app. Plus, I know those patches will *just work* for everyone. We'll see in practice if this works, but I'd much rather avoid coding custom externals for this project.

Also, does anyone know what cyclone's license is? I can't find the current version in the svn, but the old zip on the website has a BSD-like license. Having [coll] and [seq] would be very useful. It'd be nice to see these in vanilla at some point ... why reinvent the wheel?

> [1] You can certainly split symbols and count their length in Pd vanilla but it ain't
> pretty.

[list-sort] in list-abs.

--------
Dan Wilcox
danomatika.com
robotcowboy.com




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20121108/1a8dbc25/attachment-0001.htm>