none
Practical limit on the number of "task_group" instances in an application RRS feed

  • Question

  • Hi,

    Can we create a huge number (about a million or more) of task_groups within an application? Is there a pratical or design limit here?

    If there is a limit, what is it?

    Can creating a limited pool of task_groups and assigning tasks to these task_groups in a round robin way be a better approach?

    Thank you,

    Friday, November 5, 2010 11:34 AM

Answers

  • Zembunia,

    A direct answer:

    • No, there is no hard limit in the number of task groups
    • No, there is nothing in the runtime that will directly be impacted by the creation of these task groups providing another limitation.

    But (you expected that, right?)

    • If you start handing task groups across a number of hardware-thread boundaries, you introduce overhead in the search-for-work algorithms in the runtime
      (This sounds like an anti-pattern to me though)

    Lastly, I would strongly recommend you look at the agents library.  The message-passing constructs may solve your scenario.  You could also structure your work as a number of agents making up a pipeline which you manage (throttle) to keep from overloading any "bandwidth limited resources" (network, disk, etc). 

    I will mark this thread as answered.  If you want further clarification or need a deeper answer, please unmark the thread.

    Thank you for your interest in the Concurrency Runtime,

    Dana Groff


    Dana Groff, Senior Program Manager Parallel Computing, Concurrency Runtime
    • Marked as answer by Dana Groff Wednesday, November 10, 2010 9:07 PM
    Wednesday, November 10, 2010 9:07 PM

All replies

  • What are you trying to accomplish?

    Task groups are a group of tasks which you wait for completion and/or cancel together.   Why would you need a huge number of these groups?  You would also need an even larger number of tasks.  At a certain point, you just are wasting a lot of memory.

    I think you are hitting a practical limit but more, I am worried that you misunderstand the use case for task groups.  What do you want to accomplish with the task group?

    Thank you for your interest in the VS2010 Concurrency Runtime.

    Dana


    Dana Groff, Senior Program Manager Parallel Computing, Concurrency Runtime
    Friday, November 5, 2010 11:14 PM
  • Hi Dana,

    Consider a simple case where you have a continous (and endles) stream of data (say, coming from network) where you convert into data into objects as Om, O(m+1), ...O(m+n) etc. as they arrive. You have some parallel tasks Tp1, Tp2, Tpk to execute on Ox, plus some eventually one or more serial tasks which requires all parallel tasks be finished to proceed. To further clarify, first, assume that you have extensively different types of objects (not like individual pixels, lines or blocks on a frame which are all just "pixels" to compare). Second, assume you don't have to retain the order of overall processing (finishing parallel and serial tasks) of Om's.

    Given this, natural response would have been to assign one task group to each (potentiall different typed) indivudal Om's. For each such an individiual, execute parallels tasks, wait them to finsih, continue with serial tasks, and repeat this as necassary. While waiting on, say, O1, you don't want to wait on O2 or other individuals' tasks unnecassarily (isn't this one of the primary purposes of task groups?) And this also keeps locality right? (grouped tasks on the same object/data)

    Point is that in many applications as in heterogenous stream processing you could have milions of Ox objects at a time(depending on the speed of network, amount of memory, and speed of processing) .

    So the issue and task-group per (stream data) object/block sounded to me very natural.

    muharrem

    Saturday, November 6, 2010 7:34 AM
  • Millions of tasks would result in a non-functional system. It sounds like you have a natural "pipe line" architecture type of application. There are many articles on this type of implementation.
    Monday, November 8, 2010 4:17 PM
  • Millions of task_groups is not necessarily millions of task. There could be only limited number of active tasks that might have been scheduled on those task groups. Consider an Instant Messenging server with tons of active connections and sessions in which people send just occational messages or make rare requests that could be represented as as async tasks. An idea would be to have one task group per clien connection which raises the initial question.

    A pipe has limited scalability in that the maximum degree of parallelism is proportional with only the number of stages unless pipes themselve cloned which would be same as cloning task_groups???

    Best regards,

    muharrem

    Monday, November 8, 2010 7:21 PM
  • Zembunia,

    A direct answer:

    • No, there is no hard limit in the number of task groups
    • No, there is nothing in the runtime that will directly be impacted by the creation of these task groups providing another limitation.

    But (you expected that, right?)

    • If you start handing task groups across a number of hardware-thread boundaries, you introduce overhead in the search-for-work algorithms in the runtime
      (This sounds like an anti-pattern to me though)

    Lastly, I would strongly recommend you look at the agents library.  The message-passing constructs may solve your scenario.  You could also structure your work as a number of agents making up a pipeline which you manage (throttle) to keep from overloading any "bandwidth limited resources" (network, disk, etc). 

    I will mark this thread as answered.  If you want further clarification or need a deeper answer, please unmark the thread.

    Thank you for your interest in the Concurrency Runtime,

    Dana Groff


    Dana Groff, Senior Program Manager Parallel Computing, Concurrency Runtime
    • Marked as answer by Dana Groff Wednesday, November 10, 2010 9:07 PM
    Wednesday, November 10, 2010 9:07 PM
  • This is exactly what (task_group use case) I asked about in another thread recently:

    http://social.msdn.microsoft.com/Forums/vstudio/en-US/3fbb36d0-dd0e-44b2-8d50-eab67a27fb19/taskgroup-usecase?forum=parallelcppnative

    Haven't had anyone taking a stab at it yet.

    Tuesday, November 12, 2013 8:06 PM