[PD] why does PD round numbers? (in tables, in messageboxes, etc)

[katja]

Thanks for your tips, Jonathan. Anyway, while you were writing the
mail I was already doing a test patch where update times of a 32
million samples array and table are tested, see attached.

I ran the test with Pd-extended 0.43.1 and Pd-double on OSX. For an
array with that length, update takes ~3 seconds. For a table displayed
graphically, ~3.1 seconds. Surprisingly, drawing as points (instead of
polygon) takes almost 5 seconds. The deviation between repeated
measurements, a few dozen milliseconds, was about as large as the
difference between Pd-extended and Pd-double. I've verified that
double precision numbers are indeed displayed with a maximum of 14
significant digits in Pd-double.

I also checked the time for writing 32 million samples to a table
without graphical display. This took ~170 milliseconds for Pd-extended
and ~ 220 milliseconds for Pd-double.

Later I'll do another test where transmission over network is more
specifically tested.

Katja



On Tue, Apr 10, 2012 at 7:05 PM, Jonathan Wilkes <jancsika at yahoo.com> wrote:
> ----- Original Message -----
>
>> From: katja <katjavetter at gmail.com>
>> To: pd-list at iem.at
>> Cc:
>> Sent: Tuesday, April 10, 2012 9:45 AM
>> Subject: Re: [PD] why does PD round numbers? (in tables, in messageboxes, etc)
>>
>> 2012/4/10 IOhannes m zmölnig <zmoelnig at iem.at>:
>>>  On 04/10/12 10:33, katja wrote:
>>
>>>  i was talking about pd/pd-gui communication (and keep the number format for
>>>  both saving and pd/gui communication the same).
>>>  when displaying/updating a table every single number is converted to text
>>>  using printf, send over the wire and then converted back to a number for
>>>  drawing the table.
>>>  it makes a difference if you have to transmit 44100
>>>  *4 bytes or 44100*12 bytes.
>>
>> Ah I see. It is not uncommon to display complete audio files, much
>> more than 44100 samples.
>
> I've never seen a patch that _displays_ all the data for an array that large.  To
>
> transmit 44,100 drawing instructions you need a _canvas_ size of "44100" and
>
> if anyone has actually needed to do that in a patch I'd really like to see it.
>
>
>> So all these samples are converted to text
>> and back to numbers, as they go over the network?
>
> No.  See plot_vis inside g_template.c.  There is not a 1-to-1 correspondence between
> # of array elements and rectangles/polygon-coords on the tk canvas (at least for
> garrays, not sure about data structures).  If you create a 44100 element array
> and make the "size" field in that arrays canvas dialog "2", Pd will only send
> data to the gui for those 2 pixels, not for the entire array.  However, it will loop
> through the entire array on the c side _every_ time plot_vis is called, in order to
> figure out what info should be sent to the gui.
>
> For example: running with -d 3, create an array with 10,000,000 elements.
> Now make the "size" field in its canvas dialog "2".
> Select the array.
> Click an array key to move it.
> Notice the lag, but also notice Pd is only sending two commands to the gui to
> draw the elements.
> It's because Pd must loop through 5,000,000 elements before it hits the next pixel
> where it needs to send another drawing instruction to the gui!
>
>> (While in the end,
>> only a couple hundred values are displayed). And every character goes
>> through the loop in binbuf_text() with all it's cases... well that is
>> a bottleneck which should not be further aggravated.
>> At least this
>> performance issue can be quickly tested, using Pd vs Pd-double. I'll
>> make a test patch for that.
>
> Keep in mind that you're using a horribly implemented feature of Pd to do your
> test-- that is, if you're using garrays.  For example, moving an array shouldn't
>
> send _any_ element data to the gui.  It doesn't in Pd-l2ork because it just moves
>
> everything by tag, using one line of tk, thus there is no bottleneck in that case.
>
> A practical test I can think of to compare 4byte vs 12byte payload is
>
> something like [metro 100]--[tabwrite~] animation for a visible garray.  I'd be
>
> curious to know if there is a significant performance difference there.
>
>
> -Jonathan
>
>
>>
>> Katja
>>
>> _______________________________________________
>> 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: long-array-update.pd
Type: application/octet-stream
Size: 3541 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120410/9d57685d/attachment-0001.obj>