Re: [PD] abstraction penalty benchmarks
I believe it should not happen ($1-loop would expand to different symbols
depending on $1).
cheers
M
On Sat, Aug 10, 2013 at 11:23:19AM -0400, Jonathan Wilkes wrote:
> On 08/10/2013 10:37 AM, Jonathan Wilkes wrote:
> >On 08/09/2013 08:01 PM, Miller Puckette wrote:
> >>Well, if ia user really wants 32K receives of the same name,
> >>(s)he can have
> >>them - but most people won't want to do that. In contrast, you
> >>can't have
> >>32K copies of an abstraction without hitting this problem - and
> >>the business
> >>of binding patches to names is only rarely actually used. So
> >>(I'm now thinking)
> >>Pd should make it easy to defeat that useless behavior.
> >
> >So the problem doesn't happen with [s $0-loop]?
>
> I mean [r $0-loop]
>
> -Jonathan
>
> >
> >-Jonathan
> >
> >>
> >>cheers
> >>M
> >>On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote:
> >>>On 08/09/2013 04:31 PM, Miller Puckette wrote:
> Or... just limit the number of canvases that can bind
> themselves to a single
> symbol to a reasonable number (5 or so, settable by flag for
> back-compatibility
> if anyone cares).
> >>>What happens to Claude's test if you a) patch Pd to stop binding
> >>>pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd]
> >>>inside the abstraction that's getting massively replicated?
> >>>
> >>>I'd hypothesize that you end up with the same or closely
> >>>similar problem,
> >>>no?
> >>>
> >>>If so then messing with the abstraction name binding risks introducing
> >>>bugs or breaking some strange but interesting patches, and doesn't
> >>>solve the larger problem which becomes anxiety about [s]/[r] pairs or
> >>>any other nonlocal connection objects inside abstractions.
> >>>
> >>>-Jonathan
> >>>
> cheers
> M
>
> On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
> >On 09/08/13 19:42, Miller Puckette wrote:
> >>There still could be situations where an abstraction has
> >>a sub-patch ("pd foo"
> >>for instance) - I'm not clear as to whether those
> >>namings should be supressed
> >>as well. It seems like a tricky problem - lots of
> >>people seem to use
> >>abstractions with only one instance and might be
> >>depending on the bindings.
> >Maybe the best fix would be to make pd_unbind() constant
> >time (perhaps
> >by storing bindings in a doubly-linked list instead of a
> >singly-linked
> >list) and be done with it, instead of hacking workarounds..
> >
> >
> >Claude
> >--
> >http://mathr.co.uk
> >
> >
> >___
> >Pd-list@iem.at mailing list
> >UNSUBSCRIBE and account-management ->
> >http://lists.puredata.info/listinfo/pd-list
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >>>
> >>>___
> >>>Pd-list@iem.at mailing list
> >>>UNSUBSCRIBE and account-management ->
> >>>http://lists.puredata.info/listinfo/pd-list
> >
> >
> >___
> >Pd-list@iem.at mailing list
> >UNSUBSCRIBE and account-management ->
> >http://lists.puredata.info/listinfo/pd-list
> >
> >
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
On 08/10/2013 10:37 AM, Jonathan Wilkes wrote:
On 08/09/2013 08:01 PM, Miller Puckette wrote:
Well, if ia user really wants 32K receives of the same name, (s)he
can have
them - but most people won't want to do that. In contrast, you can't
have
32K copies of an abstraction without hitting this problem - and the
business
of binding patches to names is only rarely actually used. So (I'm
now thinking)
Pd should make it easy to defeat that useless behavior.
So the problem doesn't happen with [s $0-loop]?
I mean [r $0-loop]
-Jonathan
-Jonathan
cheers
M
On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote:
On 08/09/2013 04:31 PM, Miller Puckette wrote:
Or... just limit the number of canvases that can bind themselves to
a single
symbol to a reasonable number (5 or so, settable by flag for
back-compatibility
if anyone cares).
What happens to Claude's test if you a) patch Pd to stop binding
pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd]
inside the abstraction that's getting massively replicated?
I'd hypothesize that you end up with the same or closely similar
problem,
no?
If so then messing with the abstraction name binding risks introducing
bugs or breaking some strange but interesting patches, and doesn't
solve the larger problem which becomes anxiety about [s]/[r] pairs or
any other nonlocal connection objects inside abstractions.
-Jonathan
cheers
M
On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
On 09/08/13 19:42, Miller Puckette wrote:
There still could be situations where an abstraction has a
sub-patch ("pd foo"
for instance) - I'm not clear as to whether those namings should
be supressed
as well. It seems like a tricky problem - lots of people seem to
use
abstractions with only one instance and might be depending on the
bindings.
Maybe the best fix would be to make pd_unbind() constant time
(perhaps
by storing bindings in a doubly-linked list instead of a
singly-linked
list) and be done with it, instead of hacking workarounds..
Claude
--
http://mathr.co.uk
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
On 08/09/2013 08:01 PM, Miller Puckette wrote:
Well, if ia user really wants 32K receives of the same name, (s)he can have
them - but most people won't want to do that. In contrast, you can't have
32K copies of an abstraction without hitting this problem - and the business
of binding patches to names is only rarely actually used. So (I'm now thinking)
Pd should make it easy to defeat that useless behavior.
So the problem doesn't happen with [s $0-loop]?
-Jonathan
cheers
M
On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote:
On 08/09/2013 04:31 PM, Miller Puckette wrote:
Or... just limit the number of canvases that can bind themselves to a single
symbol to a reasonable number (5 or so, settable by flag for back-compatibility
if anyone cares).
What happens to Claude's test if you a) patch Pd to stop binding
pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd]
inside the abstraction that's getting massively replicated?
I'd hypothesize that you end up with the same or closely similar problem,
no?
If so then messing with the abstraction name binding risks introducing
bugs or breaking some strange but interesting patches, and doesn't
solve the larger problem which becomes anxiety about [s]/[r] pairs or
any other nonlocal connection objects inside abstractions.
-Jonathan
cheers
M
On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
On 09/08/13 19:42, Miller Puckette wrote:
There still could be situations where an abstraction has a sub-patch ("pd foo"
for instance) - I'm not clear as to whether those namings should be supressed
as well. It seems like a tricky problem - lots of people seem to use
abstractions with only one instance and might be depending on the bindings.
Maybe the best fix would be to make pd_unbind() constant time (perhaps
by storing bindings in a doubly-linked list instead of a singly-linked
list) and be done with it, instead of hacking workarounds..
Claude
--
http://mathr.co.uk
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Hi,
I looked at accelerating* pd_unbind(), but it seems impossible without
breaking binary compatibility somewhere along the line. There's simply
no space to store any implementation-private data in objects, as an
object is just a pointer to a class.
*by making a parallel bindlist per object that points to nodes in a
doubly linked bindlist per symbol, so pd_unbind(object, symbol) takes
O(symbols per object) instead of O(objects per symbol), with the former
number generally much smaller than the latter number (at least in my
experience - are there any externals that bind to a large number of
symbols? I did write one in Lua, but iirc pdlua uses one proxy object
for each binding, so that it can tell which symbol was the target of the
message).
Claude
On 10/08/13 01:06, Ivica Bukvic wrote:
> When and if such patch is implemented please do let us know as I would like
> to implement it in pd-l2ork as well.
>
> Best wishes,
>
> Ico
> On Aug 9, 2013 8:03 PM, "Miller Puckette" wrote:
>
>> Well, if ia user really wants 32K receives of the same name, (s)he can have
>> them - but most people won't want to do that. In contrast, you can't have
>> 32K copies of an abstraction without hitting this problem - and the
>> business
>> of binding patches to names is only rarely actually used. So (I'm now
>> thinking)
>> Pd should make it easy to defeat that useless behavior.
>>
>> cheers
>> M
>> On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote:
>>> On 08/09/2013 04:31 PM, Miller Puckette wrote:
Or... just limit the number of canvases that can bind themselves to a
>> single
symbol to a reasonable number (5 or so, settable by flag for
>> back-compatibility
if anyone cares).
>>>
>>> What happens to Claude's test if you a) patch Pd to stop binding
>>> pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd]
>>> inside the abstraction that's getting massively replicated?
>>>
>>> I'd hypothesize that you end up with the same or closely similar problem,
>>> no?
>>>
>>> If so then messing with the abstraction name binding risks introducing
>>> bugs or breaking some strange but interesting patches, and doesn't
>>> solve the larger problem which becomes anxiety about [s]/[r] pairs or
>>> any other nonlocal connection objects inside abstractions.
>>>
>>> -Jonathan
>>>
cheers
M
On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
> On 09/08/13 19:42, Miller Puckette wrote:
>> There still could be situations where an abstraction has a sub-patch
>> ("pd foo"
>> for instance) - I'm not clear as to whether those namings should be
>> supressed
>> as well. It seems like a tricky problem - lots of people seem to use
>> abstractions with only one instance and might be depending on the
>> bindings.
> Maybe the best fix would be to make pd_unbind() constant time (perhaps
> by storing bindings in a doubly-linked list instead of a singly-linked
> list) and be done with it, instead of hacking workarounds..
>
>
> Claude
--
http://mathr.co.uk
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
When and if such patch is implemented please do let us know as I would like
to implement it in pd-l2ork as well.
Best wishes,
Ico
On Aug 9, 2013 8:03 PM, "Miller Puckette" wrote:
> Well, if ia user really wants 32K receives of the same name, (s)he can have
> them - but most people won't want to do that. In contrast, you can't have
> 32K copies of an abstraction without hitting this problem - and the
> business
> of binding patches to names is only rarely actually used. So (I'm now
> thinking)
> Pd should make it easy to defeat that useless behavior.
>
> cheers
> M
> On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote:
> > On 08/09/2013 04:31 PM, Miller Puckette wrote:
> > >Or... just limit the number of canvases that can bind themselves to a
> single
> > >symbol to a reasonable number (5 or so, settable by flag for
> back-compatibility
> > >if anyone cares).
> >
> > What happens to Claude's test if you a) patch Pd to stop binding
> > pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd]
> > inside the abstraction that's getting massively replicated?
> >
> > I'd hypothesize that you end up with the same or closely similar problem,
> > no?
> >
> > If so then messing with the abstraction name binding risks introducing
> > bugs or breaking some strange but interesting patches, and doesn't
> > solve the larger problem which becomes anxiety about [s]/[r] pairs or
> > any other nonlocal connection objects inside abstractions.
> >
> > -Jonathan
> >
> > >
> > >cheers
> > >M
> > >
> > >On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
> > >>On 09/08/13 19:42, Miller Puckette wrote:
> > >>>There still could be situations where an abstraction has a sub-patch
> ("pd foo"
> > >>>for instance) - I'm not clear as to whether those namings should be
> supressed
> > >>>as well. It seems like a tricky problem - lots of people seem to use
> > >>>abstractions with only one instance and might be depending on the
> bindings.
> > >>Maybe the best fix would be to make pd_unbind() constant time (perhaps
> > >>by storing bindings in a doubly-linked list instead of a singly-linked
> > >>list) and be done with it, instead of hacking workarounds..
> > >>
> > >>
> > >>Claude
> > >>--
> > >>http://mathr.co.uk
> > >>
> > >>
> > >>___
> > >>Pd-list@iem.at mailing list
> > >>UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> > >___
> > >Pd-list@iem.at mailing list
> > >UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> >
> >
> > ___
> > Pd-list@iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Well, if ia user really wants 32K receives of the same name, (s)he can have
them - but most people won't want to do that. In contrast, you can't have
32K copies of an abstraction without hitting this problem - and the business
of binding patches to names is only rarely actually used. So (I'm now thinking)
Pd should make it easy to defeat that useless behavior.
cheers
M
On Fri, Aug 09, 2013 at 07:11:02PM -0400, Jonathan Wilkes wrote:
> On 08/09/2013 04:31 PM, Miller Puckette wrote:
> >Or... just limit the number of canvases that can bind themselves to a single
> >symbol to a reasonable number (5 or so, settable by flag for
> >back-compatibility
> >if anyone cares).
>
> What happens to Claude's test if you a) patch Pd to stop binding
> pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd]
> inside the abstraction that's getting massively replicated?
>
> I'd hypothesize that you end up with the same or closely similar problem,
> no?
>
> If so then messing with the abstraction name binding risks introducing
> bugs or breaking some strange but interesting patches, and doesn't
> solve the larger problem which becomes anxiety about [s]/[r] pairs or
> any other nonlocal connection objects inside abstractions.
>
> -Jonathan
>
> >
> >cheers
> >M
> >
> >On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
> >>On 09/08/13 19:42, Miller Puckette wrote:
> >>>There still could be situations where an abstraction has a sub-patch ("pd
> >>>foo"
> >>>for instance) - I'm not clear as to whether those namings should be
> >>>supressed
> >>>as well. It seems like a tricky problem - lots of people seem to use
> >>>abstractions with only one instance and might be depending on the bindings.
> >>Maybe the best fix would be to make pd_unbind() constant time (perhaps
> >>by storing bindings in a doubly-linked list instead of a singly-linked
> >>list) and be done with it, instead of hacking workarounds..
> >>
> >>
> >>Claude
> >>--
> >>http://mathr.co.uk
> >>
> >>
> >>___
> >>Pd-list@iem.at mailing list
> >>UNSUBSCRIBE and account-management ->
> >>http://lists.puredata.info/listinfo/pd-list
> >___
> >Pd-list@iem.at mailing list
> >UNSUBSCRIBE and account-management ->
> >http://lists.puredata.info/listinfo/pd-list
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
On 08/09/2013 04:31 PM, Miller Puckette wrote:
Or... just limit the number of canvases that can bind themselves to a single
symbol to a reasonable number (5 or so, settable by flag for back-compatibility
if anyone cares).
What happens to Claude's test if you a) patch Pd to stop binding
pd-abstractionName.pd, and b) put a [receive pd-abstractionName.pd]
inside the abstraction that's getting massively replicated?
I'd hypothesize that you end up with the same or closely similar problem,
no?
If so then messing with the abstraction name binding risks introducing
bugs or breaking some strange but interesting patches, and doesn't
solve the larger problem which becomes anxiety about [s]/[r] pairs or
any other nonlocal connection objects inside abstractions.
-Jonathan
cheers
M
On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
On 09/08/13 19:42, Miller Puckette wrote:
There still could be situations where an abstraction has a sub-patch ("pd foo"
for instance) - I'm not clear as to whether those namings should be supressed
as well. It seems like a tricky problem - lots of people seem to use
abstractions with only one instance and might be depending on the bindings.
Maybe the best fix would be to make pd_unbind() constant time (perhaps
by storing bindings in a doubly-linked list instead of a singly-linked
list) and be done with it, instead of hacking workarounds..
Claude
--
http://mathr.co.uk
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Or... just limit the number of canvases that can bind themselves to a single
symbol to a reasonable number (5 or so, settable by flag for back-compatibility
if anyone cares).
cheers
M
On Fri, Aug 09, 2013 at 07:51:30PM +0100, Claude Heiland-Allen wrote:
> On 09/08/13 19:42, Miller Puckette wrote:
> > There still could be situations where an abstraction has a sub-patch ("pd
> > foo"
> > for instance) - I'm not clear as to whether those namings should be
> > supressed
> > as well. It seems like a tricky problem - lots of people seem to use
> > abstractions with only one instance and might be depending on the bindings.
>
> Maybe the best fix would be to make pd_unbind() constant time (perhaps
> by storing bindings in a doubly-linked list instead of a singly-linked
> list) and be done with it, instead of hacking workarounds..
>
>
> Claude
> --
> http://mathr.co.uk
>
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
On 09/08/13 19:42, Miller Puckette wrote:
> There still could be situations where an abstraction has a sub-patch ("pd foo"
> for instance) - I'm not clear as to whether those namings should be supressed
> as well. It seems like a tricky problem - lots of people seem to use
> abstractions with only one instance and might be depending on the bindings.
Maybe the best fix would be to make pd_unbind() constant time (perhaps
by storing bindings in a doubly-linked list instead of a singly-linked
list) and be done with it, instead of hacking workarounds..
Claude
--
http://mathr.co.uk
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
There still could be situations where an abstraction has a sub-patch ("pd foo"
for instance) - I'm not clear as to whether those namings should be supressed
as well. It seems like a tricky problem - lots of people seem to use
abstractions with only one instance and might be depending on the bindings.
Maybe the rule should be that before a canvas binds itself to the symbol
it checks to see if anyone else already did and if so silently refuses
(protected with a compatibility flag as usual).
cheers
M
On Fri, Aug 09, 2013 at 03:15:52PM +0100, Claude Heiland-Allen wrote:
> Hi,
>
> On 09/08/13 04:27, Miller Puckette wrote:
> > Here's a guess - I think each copy of the abstraction binds itself to
> > a symbol, "pd-". Binding is fast bt unbinding is linear-time in the
> > number of things bound to the symbol... ouch.
>
> Yes, I think that's it:
>
> git master from yesterday
> Pd-0.45.0 ("test") compiled 17:10:02 Aug 8 2013
> patch bench opendsp saveclose
> small 4.6e-05 38.775 1.34085 44.326 4.012
> medium 5.2e-05 314.812 10.2582 715.956 144.512
> large 4.7e-05 2639.28 85.3561 78711.5 35918
>
> git master, lightly patched with the attached
> Pd-0.45.0 ("test") compiled 14:36:39 Aug 9 2013
> patch bench opendsp saveclose
> small 4.3e-05 36.167 1.31707 39.657 3.447
> medium 4.4e-05 291.52 9.8958 327.389 18.067
> large 4.3e-05 2443.07 82.0808 3628.66 224.972
>
> > There's a good reason to bind toplevels and named sub-patches to ther names,
> > but I think there's little reason to do it for abstractions - perhaps I can
> > take this out, but I'd have to leave it as an option for compatibility
> > (ouch!)
>
> The attached patch doesn't do this, but it should be easy to add a
> global compatibility flag to the new canvas_should_bind() function.
>
> Toplevel patches are still bound to pd-.pd and subpatches [pd
> ] are still bound to pd-; it's just abstraction instances
> that no longer have the automatic binding.
>
> > On Thu, Aug 08, 2013 at 10:46:24PM -0400, Jonathan Wilkes wrote:
> >> On 08/08/2013 04:57 PM, Claude Heiland-Allen wrote:
>
> [snip]
>
> >>> The killer in the bottom right corner: with 8x as many abstractions, it
> >>> takes 100x as long to save an instance, and 200x as long to close the
> >>> patch.
>
> [snip]
>
> >> Any idea why "save" is so much greater than close + open?
>
> I think Miller had the answer.
>
> >> Also, any idea what pd is doing for the bulk of that time when
>
> I haven't profiled yet (I had trouble even getting debug symbols into an
> installed Pd with the autoconf system, no success yet..), so the
> following are just guesses:
>
> >> saving
>
> searching for copies of the abstraction to reload, then reloading them
> via some select/cut/undo method (which preserves connections). also
> unbinding symbols...
>
> >> closing
>
> calling all the destructors. also unbinding symbols...
>
> >> opening
>
> refinding/reloading/reparsing/reinstantiating all the abstractions (I
> need to relocate my abstraction cache patches and update them to current Pd)
>
> >> dsp'ing?
>
> traversing each canvas to topologically sort its dsp objects and build
> the dsp chain - which gets resizebytes() each time something is added,
> could make it O(log(N)) count of resizes (doubling the size each time)
> but I tried it and it saved about 9 microseconds, not worth the extra
> complexity...
>
>
> Claude
> --
> http://mathr.co.uk
>
> From 16fd46b3abe83dba956b78385d01ad19737b6c76 Mon Sep 17 00:00:00 2001
> From: Claude Heiland-Allen
> Date: Fri, 9 Aug 2013 14:57:14 +0100
> Subject: [PATCH] don't bind abstraction instances to pd-
>
> ---
> src/g_canvas.c | 39 +--
> 1 file changed, 29 insertions(+), 10 deletions(-)
>
> diff --git a/src/g_canvas.c b/src/g_canvas.c
> index 804ac57..c7a22d6 100644
> --- a/src/g_canvas.c
> +++ b/src/g_canvas.c
> @@ -55,6 +55,9 @@ void canvas_reflecttitle(t_canvas *x);
> static void canvas_addtolist(t_canvas *x);
> static void canvas_takeofflist(t_canvas *x);
> static void canvas_pop(t_canvas *x, t_floatarg fvis);
> +static int canvas_should_bind(t_canvas *x);
> +static void canvas_bind(t_canvas *x);
> +static void canvas_unbind(t_canvas *x);
>
> /* - functions to handle the canvas environment --- */
>
> @@ -205,11 +208,9 @@ void canvas_makefilename(t_canvas *x, char *file, char
> *result, int resultsize)
>
> void canvas_rename(t_canvas *x, t_symbol *s, t_symbol *dir)
> {
> -if (strcmp(x->gl_name->s_name, "Pd"))
> -pd_unbind(&x->gl_pd, canvas_makebindsym(x->gl_name));
> +canvas_unbind(x);
> x->gl_name = s;
> -if (strcmp(x->gl_name->s_name, "Pd"))
> -pd_bind(&x->gl_pd, canvas_makebindsym(x->gl_name));
> +canvas_bind(x);
> if (x->gl_havewindow)
> canvas_reflecttitle(x);
> if (dir && dir != &s_)
> @@ -379,8 +380,7 @@ t_canvas *canvas_new(void *dummy, t_symbol *sel, int
> argc, t_at
Re: [PD] abstraction penalty benchmarks
> > Hi Miller, > > Just very generally BTW: > Do you mean binary compatibility or patch compatibility? > Either way, what are your thoughts about the possibility of a future Pd-1.0 > which would break (some kind of) compatibility for the sake of > revolutionary progress? > > András I'm unwilling to break either patch or binary compatibility - Pd's original purpose is for interactive music and art and there is a big repertory now depending on Pd to remain runnable. I'm willing to make minor compatibility changes protected by compatibility switches. Pd now maintains a global compatibility version number to try to facilitate this. (It was necessitated by two bugs in DSP objects, one rather serious, that I wanted to fix without breaking old patches that might depend on the buggy behavior.) On a side note, the reason I'm so slow to add fetures to Pd is that I want to be sure that everything I do is something I'm willing to maintain for as long as I can. cheers Miller ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Hi,
On 09/08/13 04:27, Miller Puckette wrote:
> Here's a guess - I think each copy of the abstraction binds itself to
> a symbol, "pd-". Binding is fast bt unbinding is linear-time in the
> number of things bound to the symbol... ouch.
Yes, I think that's it:
git master from yesterday
Pd-0.45.0 ("test") compiled 17:10:02 Aug 8 2013
patch bench opendsp saveclose
small 4.6e-05 38.775 1.34085 44.326 4.012
medium 5.2e-05 314.812 10.2582 715.956 144.512
large 4.7e-05 2639.28 85.3561 78711.5 35918
git master, lightly patched with the attached
Pd-0.45.0 ("test") compiled 14:36:39 Aug 9 2013
patch bench opendsp saveclose
small 4.3e-05 36.167 1.31707 39.657 3.447
medium 4.4e-05 291.52 9.8958 327.389 18.067
large 4.3e-05 2443.07 82.0808 3628.66 224.972
> There's a good reason to bind toplevels and named sub-patches to ther names,
> but I think there's little reason to do it for abstractions - perhaps I can
> take this out, but I'd have to leave it as an option for compatibility (ouch!)
The attached patch doesn't do this, but it should be easy to add a
global compatibility flag to the new canvas_should_bind() function.
Toplevel patches are still bound to pd-.pd and subpatches [pd
] are still bound to pd-; it's just abstraction instances
that no longer have the automatic binding.
> On Thu, Aug 08, 2013 at 10:46:24PM -0400, Jonathan Wilkes wrote:
>> On 08/08/2013 04:57 PM, Claude Heiland-Allen wrote:
[snip]
>>> The killer in the bottom right corner: with 8x as many abstractions, it
>>> takes 100x as long to save an instance, and 200x as long to close the patch.
[snip]
>> Any idea why "save" is so much greater than close + open?
I think Miller had the answer.
>> Also, any idea what pd is doing for the bulk of that time when
I haven't profiled yet (I had trouble even getting debug symbols into an
installed Pd with the autoconf system, no success yet..), so the
following are just guesses:
>> saving
searching for copies of the abstraction to reload, then reloading them
via some select/cut/undo method (which preserves connections). also
unbinding symbols...
>> closing
calling all the destructors. also unbinding symbols...
>> opening
refinding/reloading/reparsing/reinstantiating all the abstractions (I
need to relocate my abstraction cache patches and update them to current Pd)
>> dsp'ing?
traversing each canvas to topologically sort its dsp objects and build
the dsp chain - which gets resizebytes() each time something is added,
could make it O(log(N)) count of resizes (doubling the size each time)
but I tried it and it saved about 9 microseconds, not worth the extra
complexity...
Claude
--
http://mathr.co.uk
>From 16fd46b3abe83dba956b78385d01ad19737b6c76 Mon Sep 17 00:00:00 2001
From: Claude Heiland-Allen
Date: Fri, 9 Aug 2013 14:57:14 +0100
Subject: [PATCH] don't bind abstraction instances to pd-
---
src/g_canvas.c | 39 +--
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/src/g_canvas.c b/src/g_canvas.c
index 804ac57..c7a22d6 100644
--- a/src/g_canvas.c
+++ b/src/g_canvas.c
@@ -55,6 +55,9 @@ void canvas_reflecttitle(t_canvas *x);
static void canvas_addtolist(t_canvas *x);
static void canvas_takeofflist(t_canvas *x);
static void canvas_pop(t_canvas *x, t_floatarg fvis);
+static int canvas_should_bind(t_canvas *x);
+static void canvas_bind(t_canvas *x);
+static void canvas_unbind(t_canvas *x);
/* - functions to handle the canvas environment --- */
@@ -205,11 +208,9 @@ void canvas_makefilename(t_canvas *x, char *file, char *result, int resultsize)
void canvas_rename(t_canvas *x, t_symbol *s, t_symbol *dir)
{
-if (strcmp(x->gl_name->s_name, "Pd"))
-pd_unbind(&x->gl_pd, canvas_makebindsym(x->gl_name));
+canvas_unbind(x);
x->gl_name = s;
-if (strcmp(x->gl_name->s_name, "Pd"))
-pd_bind(&x->gl_pd, canvas_makebindsym(x->gl_name));
+canvas_bind(x);
if (x->gl_havewindow)
canvas_reflecttitle(x);
if (dir && dir != &s_)
@@ -379,8 +380,7 @@ t_canvas *canvas_new(void *dummy, t_symbol *sel, int argc, t_atom *argv)
x->gl_owner = owner;
x->gl_name = (*s->s_name ? s :
(canvas_newfilename ? canvas_newfilename : gensym("Pd")));
-if (strcmp(x->gl_name->s_name, "Pd"))
-pd_bind(&x->gl_pd, canvas_makebindsym(x->gl_name));
+canvas_bind(x);
x->gl_loading = 1;
x->gl_goprect = 0; /* no GOP rectangle unless it's turned on later */
/* cancel "vis" flag if we're a subpatch of an
@@ -479,9 +479,8 @@ t_glist *glist_addglist(t_glist *g, t_symbol *sym,
x->gl_screeny1 = GLIST_DEFCANVASYLOC;
x->gl_screenx2 = 450;
x->gl_screeny2 = 300;
-if (strcmp(x->gl_name->s_name, "Pd"))
-pd_bind(&x->gl_pd, canvas_makebindsym(x->gl_name));
x->gl_owner = g;
+canvas_bind(x);
x->gl_isgraph = 1;
x->gl_goprect = 0;
x->gl_obj.te_binbuf = binbuf_new();
@@ -7
Re: [PD] abstraction penalty benchmarks
On Fri, Aug 9, 2013 at 5:27 AM, Miller Puckette wrote: > Here's a guess - I think each copy of the abstraction binds itself to > a symbol, "pd-". Binding is fast bt unbinding is linear-time in the > number of things bound to the symbol... ouch. > > There's a good reason to bind toplevels and named sub-patches to ther > names, > but I think there's little reason to do it for abstractions - perhaps I can > take this out, but I'd have to leave it as an option for compatibility > (ouch!) > > Miller Hi Miller, Just very generally BTW: Do you mean binary compatibility or patch compatibility? Either way, what are your thoughts about the possibility of a future Pd-1.0 which would break (some kind of) compatibility for the sake of revolutionary progress? András ___ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
Here's a guess - I think each copy of the abstraction binds itself to
a symbol, "pd-". Binding is fast bt unbinding is linear-time in the
number of things bound to the symbol... ouch.
There's a good reason to bind toplevels and named sub-patches to ther names,
but I think there's little reason to do it for abstractions - perhaps I can
take this out, but I'd have to leave it as an option for compatibility (ouch!)
Miller
On Thu, Aug 08, 2013 at 10:46:24PM -0400, Jonathan Wilkes wrote:
> On 08/08/2013 04:57 PM, Claude Heiland-Allen wrote:
> >Hi,
> >
> >Today I remembered one performance where I saved an abstraction with
> >many instances, bringing things to a halt. So I benchmarked this
> >scenario and some similar ones - some seem to scale very badly.
> >
> >pure-data.git gcc-4.8.1 GNU/Linux/Debian/Wheezy amd64 64bit
> >Pd-0.45.0 ("test") compiled 17:10:02 Aug 8 2013
> >
> >m n open dsp save close
> >351238.503 1.33879 44.26 3.985
> >4 4096 324.507 10.7379 786.227150.602
> >5 32768 2611.92 85.40579234.235853
> >
> >keydescription
> >m number of levels of nested abstractions
> >n total number of instances at deepest level
> >open time to load patch
> >dsptime to toggle dsp on then off (1000 runs averaged)
> >save time to save one instance at deepest level
> >close time to close patch
> >
> >all times are in ms, measured with [realtime]
> >rows run sequentially in their own pd instance
> >dsp was off at the start of each test
> >the whole run is in zero logical time
> >cpu frequency scaling was disabled (for real)
> >pd was run with -nogui -nosound -nrt
> >
> >The killer in the bottom right corner: with 8x as many abstractions, it
> >takes 100x as long to save an instance, and 200x as long to close the patch.
> >
> >See attached tarball if you want to try it yourself.
>
> Thanks for the stats.
>
> Any idea why "save" is so much greater than close + open?
>
> Also, any idea what pd is doing for the bulk of that time when
> saving, closing, opening, and dsp'ing?
>
> -Jonathan
>
> >
> >
> >Claude
> >
> >
> >___
> >Pd-list@iem.at mailing list
> >UNSUBSCRIBE and account-management ->
> >http://lists.puredata.info/listinfo/pd-list
>
> ___
> Pd-list@iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] abstraction penalty benchmarks
On 08/08/2013 04:57 PM, Claude Heiland-Allen wrote:
Hi,
Today I remembered one performance where I saved an abstraction with
many instances, bringing things to a halt. So I benchmarked this
scenario and some similar ones - some seem to scale very badly.
pure-data.git gcc-4.8.1 GNU/Linux/Debian/Wheezy amd64 64bit
Pd-0.45.0 ("test") compiled 17:10:02 Aug 8 2013
m n open dsp save close
351238.503 1.33879 44.26 3.985
4 4096 324.507 10.7379 786.227150.602
5 32768 2611.92 85.40579234.235853
keydescription
m number of levels of nested abstractions
n total number of instances at deepest level
open time to load patch
dsptime to toggle dsp on then off (1000 runs averaged)
save time to save one instance at deepest level
close time to close patch
all times are in ms, measured with [realtime]
rows run sequentially in their own pd instance
dsp was off at the start of each test
the whole run is in zero logical time
cpu frequency scaling was disabled (for real)
pd was run with -nogui -nosound -nrt
The killer in the bottom right corner: with 8x as many abstractions, it
takes 100x as long to save an instance, and 200x as long to close the patch.
See attached tarball if you want to try it yourself.
Thanks for the stats.
Any idea why "save" is so much greater than close + open?
Also, any idea what pd is doing for the bulk of that time when
saving, closing, opening, and dsp'ing?
-Jonathan
Claude
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
[PD] abstraction penalty benchmarks
Hi,
Today I remembered one performance where I saved an abstraction with
many instances, bringing things to a halt. So I benchmarked this
scenario and some similar ones - some seem to scale very badly.
pure-data.git gcc-4.8.1 GNU/Linux/Debian/Wheezy amd64 64bit
Pd-0.45.0 ("test") compiled 17:10:02 Aug 8 2013
m n open dsp save close
351238.503 1.33879 44.26 3.985
4 4096 324.507 10.7379 786.227150.602
5 32768 2611.92 85.40579234.235853
keydescription
m number of levels of nested abstractions
n total number of instances at deepest level
open time to load patch
dsptime to toggle dsp on then off (1000 runs averaged)
save time to save one instance at deepest level
close time to close patch
all times are in ms, measured with [realtime]
rows run sequentially in their own pd instance
dsp was off at the start of each test
the whole run is in zero logical time
cpu frequency scaling was disabled (for real)
pd was run with -nogui -nosound -nrt
The killer in the bottom right corner: with 8x as many abstractions, it
takes 100x as long to save an instance, and 200x as long to close the patch.
See attached tarball if you want to try it yourself.
Claude
--
http://mathr.co.uk
benchmark.tar.bz2
Description: Binary data
___
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
