Task Queue, Graph Partitioning Etc.

Task Queue confuses me. It seems that all it is attempting to do is build a list of executable units, and then, as space opens, distribute those units amongst the available resources. But this seems like something the Operating System is supposed to as part of its normal operation. And since the queue system needs a system like Fork Join in order to distribute the tasks and do things like task stealing I'm not sure I understand what this is trying to accomplish that standard system doesn't already accomplish during its standard work. It also doesn't seem like there is much difference in intent than the pipes and filters pattern of dealing with multiple tasks of varying lengths and deciding how to move between them and begin those steps.

The Loop Parallelism paper reminds me of the discussions in the computer architecture courses that go over how to unroll loops and the complexities involved in that. It seems like this paper wants to use those same techniques whenever possible and assign the unrolled portions to different processors. Unfortunately I think this would severely limit the kinds of loops that this can be applied to, especially since many loops involve cumulative work on the components. When we read about the various multicore data structures like the parallel array there was a realization that scans of it would be easy to parallelize, but some alterations would be too difficult to do and maintain data integrity. Additionally, the architecture classes point out the amount of additional work that must be done to make the answers from the various stages of the loop pipeline available elsewhere. Combine these two ideas, of the necessary hardware additions for efficiency, and the restrictions of the way to use the structures in the code itself and I'm not sure I'm grasping why this would be more useful than either the techinques in wide use today or some of the tools and techniques we've already examined.