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