discuss TBB revamp #320
Assignees
Labels
Comments
|
One feature that was a major hassle in the original integration was a global wait for all tasks. This cannot be done within tbb. |
|
Jeff ... thanks for the heads up on this. We also have ParSEC as a back end now and it might be timely for us to contribute to the TBB discussion. |
|
related to this (and overdue): the need to remove deprecated functionality, e.g. tbb_scheduler_init in favor of https://software.intel.com/en-us/node/589744 etc. |
|
Given source changes are required to migrate to oneTBB, question of testing does arise. I see following places in the code that do use deprecated task API :
What is the right way to make sure the changes does not break anything? |
|
The TBB version detection and libraries also need fixing in cmake, etc.
It might be worth a chat about the design since we have been, for want of a
better word, "fighting" TBB since (at least historically) it would not be
happy if we started a separate thread for communication (so we had to
submit a task that had to do gymnastics in order to force it to actually
run with the TBB lazy scheduling) and similarly when submitting a few large
granularity tasks it was hard to get them to run promptly.
…On Fri, Jan 29, 2021 at 10:08 AM Anton Potapov ***@***.***> wrote:
Given source changes are required to migrate to oneTBB, question of
testing does arise. I see following places in the code that do use
deprecated task API :
- RMI
- begin
- end
- ThreadPool
- add
- run_task
What is the right way to make sure the changes does not break
anything?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#320 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABZSAPMLJX6V3US77TBBHMTS4LFOZANCNFSM4JJX5J3A>
.
--
Robert J. Harrison
tel: 865-274-8544
|
Yes, definitely. However it seems to me the least problem at the moment.
It would be great! But in order to propose the efficient design I need better understanding of desired behavior.
Is
Could you please elaborate more on this ? Some more questions from my side :
|
|
Yes, starting the RMI task was the issue. But by far preferable would be
to not use a task and just use a separate thread for communication. Is TBB
now OK with other threads in the app?
The large granularity tasks is the same issue ... we need tasks to be run
eagerly instead of aggregating a few before execution starts.
The old thread pool implementation has a taskq that is shared by all
threads. To reduce contention, run_tasks() gets multiple tasks from the q
instead of just 1 at a time. Also, the old implementation could execute
with just one thread (which helps with debugging) since once all tasks were
submitted the main thread would just start executing tasks. This does not
seem possible with TBB, but is still desirable.
High priority is used a lot, and can be quite beneficial for performance,
but is likely not essential. Basically, we have a bimodal task
distribution. Lots of small tasks that do little but either book keeping,
or spawn work, or hide the latency of asynchronous communication ... some
of these are submitted as high priority since they are either on the
critical path or are responsible for spawning parallelism. Larger tasks
doing actual work are usually just normal priority.
…On Thu, Feb 4, 2021 at 6:22 AM Anton Potapov ***@***.***> wrote:
The TBB version detection and libraries also need fixing in cmake, etc.
Yes, definitely. However it seems to me the least problem at the moment.
It might be worth a chat about the design
It would be great! But in order to propose the efficient design I need
better understanding of desired behavior.
since we have been, for want of a better word, "fighting" TBB since (at
least historically) it would not be happy if we started a separate thread
for communication (so we had to submit a task that had to do gymnastics in
order to force it to actually run with the TBB lazy scheduling)
Is RmiTask::execute and RMI::begin the gymnastics that mentioned above?
and similarly when submitting a few large granularity tasks it was hard to
get them to run promptly.
Could you please elaborate more on this ?
Some more questions from my side :
- What ThreadPool::run_taskis intended for ? Can it be simply {return
false;} (As it seems does not break anything) ?
- I see no test that are affected by commenting out TBB part of
RMI::begin. Is it intended or do I something wrong ?
- is HIGHPRIORITY feature of madness in use ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#320 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABZSAPL3WLQFA4AMV2GABDDS5J7ODANCNFSM4JJX5J3A>
.
--
Robert J. Harrison
tel: 865-274-8544
|
|
@robertjharrison , it seems that right now I do not have a proper answers to your questions (as I do not a have enough understanding of the issues at the moment). What I suggest lets try to migrate to oneTBB as is, and try to think for more straightforward solution in parallel (or during migration). As a first step here is PR to reduce usage of deprecated API. |
|
What is the status of this? Currently linking to oneTBB is totally broken: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The TBB team is working on a major update to align TBB with C++11. This involves removing features that are redundant with C++11/14/17.
See https://software.intel.com/sites/default/files/managed/d5/97/TBBRevamp.pdf for details.
@robertjharrison @evaleev @m-a-d-n-e-s-s/tbb-maintainers this is a good time to (1) protest deprecation of features you can't live without or mitigate and (2) request new features.
The text was updated successfully, but these errors were encountered: