test? https://github.com/pure-data/pure-data/pull/346 https://github.com/pure-data/pure-data/pull/346
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox danomatika@gmail.com wrote:
That will add a malloc/free for every method call to a msg box. So I'd measure the performance impact before using that implementation.
On the l2ork dev list I mentioned a potential way to cache the glist in the t_messresponder to avoid allocation at message evaluation time. But we haven't implemented that yet (nor measured the current performance hit).
-Jonathan
--------Dan Wilcox@danomatikadanomatika.comrobotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I don't think it makes sense to have a malloc() and free() for each call to a msg box. Pd is already not very real-time friendly, why make it worse? There could be ...
- statically allocated memory for t_gstack y in pd_pushsym
- a pre-allocated memory pool meant for short-lived memory allocations to be used in real-time critical cases like this. If no memory available from the pool, only then allocate it (or allocate a new pool).
There are probably other cases around the codebase where this would make sense, but why not starting with this?
Giulio
On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox danomatika@gmail.com wrote:
That will add a malloc/free for every method call to a msg box. So I'd measure the performance impact before using that implementation.
On the l2ork dev list I mentioned a potential way to cache the glist in the t_messresponder to avoid allocation at message evaluation time. But we haven't implemented that yet (nor measured the current performance hit).
-Jonathan
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
The second lazy-load option might work pretty well, but what would the per-instance/threading considerations be?
On Apr 6, 2018, at 12:21 PM, Giulio Moro giuliomoro@yahoo.it wrote:
I don't think it makes sense to have a malloc() and free() for each call to a msg box. Pd is already not very real-time friendly, why make it worse? There could be ...
- statically allocated memory for t_gstack y in pd_pushsym
- a pre-allocated memory pool meant for short-lived memory allocations to be used in real-time critical cases like this. If no memory available from the pool, only then allocate it (or allocate a new pool).
There are probably other cases around the codebase where this would make sense, but why not starting with this?
Giulio
On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox danomatika@gmail.com wrote:
That will add a malloc/free for every method call to a msg box. So I'd measure the performance impact before using that implementation.
On the l2ork dev list I mentioned a potential way to cache the glist in the t_messresponder to avoid allocation at message evaluation time. But we haven't implemented that yet (nor measured the current performance hit).
-Jonathan
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
On Friday, April 6, 2018, 6:24:13 AM EDT, Giulio Moro via Pd-list pd-list@lists.iem.at wrote:
I don't think it makes sense to have a malloc() and free() for each call to a msg box. Pd is already not very real-time friendly, why make it worse? There could be ...
- statically allocated memory for t_gstack y in pd_pushsym
But you can nest arbitrarily deep in patch loading, no? Also, patch loading time typically doesn't need to happen in realtime, as you're also allocating memory for objects during that time plus probably taking an i/o hit when loading abstractions.
On the other hand, it would be interesting to use a memory pool like you mention below and see its effect on load time. At least for the "canvas" field of data structures in Purr Data I cache the binbuf so there's no i/o hit there, only memory allocations.
- a pre-allocated memory pool meant for short-lived memory allocations to be used in real-time critical cases like this. If no memory available from the pool, only then allocate it (or allocate a new pool). There are probably other cases around the codebase where this would make sense, but why not starting with this?
I'd measure performance here first to determine the best course of action.Even with a memory pool pd_pushsym is doing quite a few assignments. Pushing and popping on every msg box method may get be noticeably different than dereferencing a single cached value. Measuring [trigger] performance I could see differences depending on how exactly the loop for the outlets was constructed. -Jonathan
Giulio
On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox danomatika@gmail.com wrote:
That will add a malloc/free for every method call to a msg box. So I'd measure the performance impact before using that implementation.
On the l2ork dev list I mentioned a potential way to cache the glist in the t_messresponder to avoid allocation at message evaluation time. But we haven't implemented that yet (nor measured the current performance hit).
-Jonathan
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Yeah sorry I have no idea how deep these nest, I am not familiar with that part of the code. In this case the memory could be allocated in the stack and then passed to something like pd_pushsymnoalloc(t_pd *x, t_gstack* y) which should in turn skip the allocation. But yes, a cached value seems to make much more sense.
On the topic of pre-allocated memory pools, SuperCollider, for one, uses a pre-allocated pool https://github.com/supercollider/supercollider/blob/master/common/SC_AllocPo... it throws an exception upon failure instead of allocating more memory.
Best, Giulio
On Friday, 6 April 2018, 13:42:26 BST, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote: On Friday, April 6, 2018, 6:24:13 AM EDT, Giulio Moro via Pd-list pd-list@lists.iem.at wrote:
I don't think it makes sense to have a malloc() and free() for each call to a msg box. Pd is already not very real-time friendly, why make it worse? There could be ...
- statically allocated memory for t_gstack y in pd_pushsym
But you can nest arbitrarily deep in patch loading, no?
Also, patch loading time typically doesn't need to happen in realtime, as you're also allocating memory for objects during that time plus probably taking an i/o hit when loading abstractions.
On the other hand, it would be interesting to use a memory pool like you mention below and see its effect on load time. At least for the "canvas" field of data structures in Purr Data I cache the binbuf so there's no i/o hit there, only memory allocations.
- a pre-allocated memory pool meant for short-lived memory allocations to be used in real-time critical cases like this. If no memory available from the pool, only then allocate it (or allocate a new pool). There are probably other cases around the codebase where this would make sense, but why not starting with this?
I'd measure performance here first to determine the best course of action. Even with a memory pool pd_pushsym is doing quite a few assignments. Pushing and popping on every msg box method may get be noticeably different than dereferencing a single cached value.
Measuring [trigger] performance I could see differences depending on how exactly the loop for the outlets was constructed.
-Jonathan
Giulio
On Thursday, 5 April 2018, 22:54:44 BST, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
On Thursday, April 5, 2018, 3:20:03 PM EDT, Dan Wilcox danomatika@gmail.com wrote:
That will add a malloc/free for every method call to a msg box. So I'd measure the performance impact before using that implementation.
On the l2ork dev list I mentioned a potential way to cache the glist in the t_messresponder to avoid allocation at message evaluation time. But we haven't implemented that yet (nor measured the current performance hit).
-Jonathan
Dan Wilcox @danomatika danomatika.com robotcowboy.com
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Friday, April 6, 2018, 11:21:05 AM EDT, Christof Ressi christof.ressi@gmx.at wrote:
here's an alternative implementation which uses no additional memory > allocations but is more invasive: https://github.com/pure-data/pure-data/pull/347
Here's the beginning of another implementation with some performance tests:https://git.purrdata.net/jwilkes/purr-data/merge_requests/199 Performance looks decent on armv7l and it doesn't require changes to binbuf_eval. -Jonathan
On Saturday, April 7, 2018, 10:23:31 PM EDT, Jonathan Wilkes via Pd-list pd-list@lists.iem.at wrote:
On Friday, April 6, 2018, 11:21:05 AM EDT, Christof Ressi christof.ressi@gmx.at wrote:
here's an alternative implementation which uses no additional memory >> allocations but is more invasive: https://github.com/pure-data/pure-data/pull/347Here's the beginning of another implementation with some performance tests:https://git.purrdata.net/jwilkes/purr-data/merge_requests/199
This has now been merged into 2.5.1. -Jonathan
2018-04-05 16:17 GMT-03:00 Dan Wilcox danomatika@gmail.com:
wow, didn't see that coming :) THANKS!
Well, since I opened this thread and mentioned I wanted to do such a Pull Request, let me respond so some issues raised here. One argument against this - and one that had me going there - was the inconsistency that $0 in messages is part of the same thing as arguments, and that $0 in messages should be the selector. But this has been challenged and shown inconsistent on its own, as then $0 should be the abstraction name, so I'm not convinced.
I actually always thought/perceived $0 as something else, a third usage/case of dollarsigns. I guess many considered so, as many of us were confused as to why not $0 don't work in messages. Hence, I'm actually interested and after a canonical and formal definition of $0, for the sole purpose I don't say stupid things to my students. I checked Pd's tutorial (14.dollarsigns.pd), and it says that the different behaviour in objects and messages "*may sound inconsistent, but it's not. Object and message boxes are both actually messages, but in the case of the Object box the message is passed at creation time, and for the Message box, at message time*". As I read it, I don't find a conflict or inconsistency if "$0" also gets evaluated and passed at "message time".
So after all the discussion, I still can't see the issue, as $0 becoming 0 doesn't seem of any use or a good behaviour. But I'm still open to more clarification. Now, a reasoning in favor of adopting this is that Purr Data is using it. Not that I think Pd should really adopt anything that a fork decides to do, on the contrary, but it's hard not to see this does matter, as many users are now comfortable, happy and abusing this feature in Purr Data, and those patches can't run in Pd.
cheers
On Don, 2018-04-05 at 21:17 +0200, Dan Wilcox wrote:
Better do than talk, hey? ;-)
Works fine and is definitely convenient. Can't see any disadvantage or problem with compatibility, though it challenges my notion of how things are supposed to be. When nobody is looking, I clandestinely click a message box containing '$0' that has NOTHING CONNECTED TO ITS INLET! *shiver* ;-)
Roman
-
Alexandre Torres Porres -
Christof Ressi -
Dan Wilcox -
Giulio Moro -
Jonathan Wilkes -
Roman Haefeli