Niklas Klügel wrote:
about the issues of explicitely threading parts of the graph (that came up in the discussion lateron), i must say i don't get why you would want to do it.
Because it's cheaper to implement.
If well done, it's also an intermediate step towards automatic threading. It's important to cut hard goals into easier goals, because it reduces required investment and gives quicker returns.
Also, I wouldn't trust automatic threading to make use of the CPUs in the best possible way all of the time, *especially* for real-time.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Because it's cheaper to implement.
If well done, it's also an intermediate step towards automatic threading. It's important to cut hard goals into easier goals, because it reduces required investment and gives quicker returns.
I think that's a very good point. It could also lead to some new insights into the problem as a whole, during testing. Top-down design is usually difficult because of misc problems you will find later on. I am curious... what kind of changes do you think would have to be made to allow this function?
I can imagine this explicit threading as a new type of sub-patch, which could be invoked in the same manner as [pd new_subpatch]. You could let the original process handle all the memory allocation, and switch on the new thread once its dependencies are satisfied.
Also, I wouldn't trust automatic threading to make use of the CPUs in the best possible way all of the time, *especially* for real-time.
I would have to say... there's just no replacement for actually measuring the performance and making adjustments. but you'll always be limited by the rate you can make the modifications yourself. So, some kind of algorithm could be used to optimize performance, say, genetic algorithm style, or heuristic search. So that you would create a patch which is intended to be used in a parallel arch and then you just sit back and let the computer try to optimize it by actually computing a bunch of cycles and taking measurements. Given that it's just a far off idea (to me), it's too soon to really discuss optimization :) but if the computer were to actually take measurements and choose the best, I would trust the computer to do it faster/better than I could
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Just to offer my two cents...
The great majority of DSP objects are side-effect-free and thread-safe. In the base Pd distribution, I believe the main ones which are not are delread~/write~ (etc), tabread~/write~ (etc), send~/receive~, throw~/catch~, expr~, and dac~. If these objects were avoided (or threadsafe versions written), then DSP networks could be parallelized at will.
Unfortunately, I have no idea what other objects there are (in the many externs and libraries available) that might be thread-unsafe, and what's more, I don't think there's any reliable way to determine that an object is threadsafe. So a parallelized version of Pd would, in practice, occasionally crash mysteriously. Furthermore, as new DSP objects get written new sources of crashes would appear, leaving us in all liklihood in a situation where no version of Pd ever emerged that was entirely free of thread-related crashes. Not a real pretty sight.
Another possibility would be to make Pd open up several address spaces and run portions of the patch in then. This was how Max/FTS worked on the ISPW. It wasn't pleasant to use, though; for instance, a table on one processor could easily get out of sync with one of the same name on another.
So it's hard to figure out what to do that would really help...
cheers Miller
On Thu, May 31, 2007 at 06:49:44PM -0500, Charles Henry wrote:
Because it's cheaper to implement.
If well done, it's also an intermediate step towards automatic threading. It's important to cut hard goals into easier goals, because it reduces required investment and gives quicker returns.
I think that's a very good point. It could also lead to some new insights into the problem as a whole, during testing. Top-down design is usually difficult because of misc problems you will find later on. I am curious... what kind of changes do you think would have to be made to allow this function?
I can imagine this explicit threading as a new type of sub-patch, which could be invoked in the same manner as [pd new_subpatch]. You could let the original process handle all the memory allocation, and switch on the new thread once its dependencies are satisfied.
Also, I wouldn't trust automatic threading to make use of the CPUs in the best possible way all of the time, *especially* for real-time.
I would have to say... there's just no replacement for actually measuring the performance and making adjustments. but you'll always be limited by the rate you can make the modifications yourself. So, some kind of algorithm could be used to optimize performance, say, genetic algorithm style, or heuristic search. So that you would create a patch which is intended to be used in a parallel arch and then you just sit back and let the computer try to optimize it by actually computing a bunch of cycles and taking measurements. Given that it's just a far off idea (to me), it's too soon to really discuss optimization :) but if the computer were to actually take measurements and choose the best, I would trust the computer to do it faster/better than I could
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - t?l:+1.514.383.3801, Montr?al QC Canada _______________________________________________ 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
On Thu, 31 May 2007, Miller Puckette wrote:
The great majority of DSP objects are side-effect-free and thread-safe.
On average it doesn't matter, because video is the high-bandwidth, high-crunching task, while audio is becoming (or already is) low-bandwidth, low-crunching, in comparison to the machine's capacity, even without using SIMD. There still isn't any pd DSP subsystem that carries video (there was one in jMax...).
what's more, I don't think there's any reliable way to determine that an object is threadsafe.
A reliable way to determine is to look up a table that lists all the object classes that are known to be threadsafe. That's at least as reliable as the humans that certify the threadsafeness.
So a parallelized version of Pd would, in practice, occasionally crash mysteriously.
Only if there are object classes in that list, that shouldn't be there.
Furthermore, as new DSP objects get written new sources of crashes would appear, leaving us in all liklihood in a situation where no version of Pd ever emerged that was entirely free of thread-related crashes. Not a real pretty sight.
If there are any crashes that you can't debug, you can still reduce the amount of threadliness.
Almost all race-conditions in pd would result in wrong output instead of crashes. If you want to address threading issues, consider all race-conditions, not just crashes.
Another possibility would be to make Pd open up several address spaces and run portions of the patch in then. This was how Max/FTS worked on the ISPW.
With or without shared memory?
Just to offer my two cents...
USA's currency is falling down nowadays.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
On Thu, 31 May 2007, Charles Henry wrote:
If well done, it's also an intermediate step towards automatic threading. It's important to cut hard goals into easier goals, because it reduces required investment and gives quicker returns.
I think that's a very good point. It could also lead to some new insights into the problem as a whole, during testing.
That's an important point of Extreme Programming. Suppose you always work on a new project with different goals than all your previous projects. Then you don't have the experience necessary to design the program because you need to know what happens when implementing it. Therefore you design as you need it, you grow a design gradually so that you can use the experience that you gain implementing it, to redesign existing parts or design further parts.
Top-down design is usually difficult because of misc problems you will find later on.
Top-down design on its own doesn't work. It needs to be complemented by bottom-up design, but a good corporate designer can conceal that fact from the Inquisition and even from himself.
(Bottom-up design on its own doesn't work either)
I am curious... what kind of changes do you think would have to be made to allow this function?
I'm not that deep into it yet, so I cannot talk so much about it. I shouldn't be thinking that much about threading before the conference, or even this year at all.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
Mathieu Bouchard wrote:
Niklas Klügel wrote:
about the issues of explicitely threading parts of the graph (that came up in the discussion lateron), i must say i don't get why you would want to do it.
Because it's cheaper to implement.
If well done, it's also an intermediate step towards automatic threading. It's important to cut hard goals into easier goals, because it reduces required investment and gives quicker returns.
yes, I totally agree but I was curious about the technical aspects and not necessarily about the development process that naturally has to obey these rules.
Also, I wouldn't trust automatic threading to make use of the CPUs in the best possible way all of the time, *especially* for real-time.
well, afair an algorithm for the optimal solution would be in NP anyway. if a suboptimal solution is enough, i think you can use it in a realtime system very well; ableton live for example scales with multiple cores/cpus.
so long... Niklas
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list