- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi all..
Just curious whether the situation described in the "Re: tbb::pipeline instance using excessive CPU when idle" posts is still present. I have bursty input which may take up to a second to appear.. meanwhile the cores should be busy tending to the needs of the other processes on the system if there are no TBB tasks. I also have stages in the pipeline which read files (though a cache greatly reduces the time taken here).
It seems like it would be nice to take a cue from QuickThreads and have the TBB threads block after a tuneable spin-time if they cannot find a runnable task rather than shutdown the pipeline then restart it once input arrives. Maybe it's not such a big cost, but for others it might be if their input is more bursty.
Does the tbb::graph help with this? My pipeline code is linked to a host process and we both link dynamically to TBB 2.2 so i may not be able to use it anyway.
thanks!
Just curious whether the situation described in the "Re: tbb::pipeline instance using excessive CPU when idle" posts is still present. I have bursty input which may take up to a second to appear.. meanwhile the cores should be busy tending to the needs of the other processes on the system if there are no TBB tasks. I also have stages in the pipeline which read files (though a cache greatly reduces the time taken here).
It seems like it would be nice to take a cue from QuickThreads and have the TBB threads block after a tuneable spin-time if they cannot find a runnable task rather than shutdown the pipeline then restart it once input arrives. Maybe it's not such a big cost, but for others it might be if their input is more bursty.
Does the tbb::graph help with this? My pipeline code is linked to a host process and we both link dynamically to TBB 2.2 so i may not be able to use it anyway.
thanks!
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
"It seems like it would be nice to take a cue from QuickThreads and
have the TBB threads block after a tuneable spin-time if they cannot
find a runnable task rather than shutdown the pipeline then restart it
once input arrives."
I thought that TBB already has threads block after a short spin time, and that any shutdown of the pipeline is your own decision?
How much overhead does it take, anyway, to shut down a pipeline that has no input available? If you don't do it, the thread that's blocked is not available to do anything else, which has to be taken into account as well. Does anyone have numbers for that, and how does it break down between performance and latency, which may matter greatly depending on the application? Of course, it would also be nice to also have support for task blockability (a task would dynamically declare whether it expects to spend most of its time waiting when (re)spawned) and use it for a blockable input stage...
I thought that TBB already has threads block after a short spin time, and that any shutdown of the pipeline is your own decision?
How much overhead does it take, anyway, to shut down a pipeline that has no input available? If you don't do it, the thread that's blocked is not available to do anything else, which has to be taken into account as well. Does anyone have numbers for that, and how does it break down between performance and latency, which may matter greatly depending on the application? Of course, it would also be nice to also have support for task blockability (a task would dynamically declare whether it expects to spend most of its time waiting when (re)spawned) and use it for a blockable input stage...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The situation described in the referenced discussion is still present:if the pipeline's input stage blocks a worker thread, all other worker threads eventually will go sleep, but the master thread that started the pipeline will remain busy-waiting. Note the first part: TBB threads will go sleep; that's what Raf also mentions in his answer.
tbb::graph may help, as long as you do not call its wait_for_all() method. If you call it, the main thread will enter the task dispatch loop and behave identical to what I described above. However with graph it is easier to organize the computations in such a way that the main thread waits for bursty input and passes it down the graph, and only calls wait_for_all() when it's clear that the input stream has stopped.
Another workaround is direct use of task::enqueue(), which however is available since TBB 3.0. I recommend you to upgrade :)
tbb::graph may help, as long as you do not call its wait_for_all() method. If you call it, the main thread will enter the task dispatch loop and behave identical to what I described above. However with graph it is easier to organize the computations in such a way that the main thread waits for bursty input and passes it down the graph, and only calls wait_for_all() when it's clear that the input stream has stopped.
Another workaround is direct use of task::enqueue(), which however is available since TBB 3.0. I recommend you to upgrade :)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the info! I would like to upgrade, but the host application which loads my plugin and one of the libraries the plugin links to are dynamically linked against 2.2 so i'm not sure if i can use 3.0.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page