- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As I understand, in TBB we focus on task creation. The thread creation is taken care of by TBB internally. Now, if there is an error, what tools can I use to debug issues? The query is more specifically about understanding which threads created by TBB are being used for computation (in a loop or a task) and the others which could be status threads or that are sleeping or inactive. The problem statement is about understanding which threads to focus and which ones are causing issues? What kind of debugger that I can use?
thank you.
regards,
rama
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As I understand, in TBB we focus on task creation. The thread creation is taken care of by TBB internally. Now, if there is an error, what tools can I use to debug issues? The query is more specifically about understanding which threads created by TBB are being used for computation (in a loop or a task) and the others which could be status threads or that are sleeping or inactive. The problem statement is about understanding which threads to focus and which ones are causing issues? What kind of debugger that I can use?
Hi,
a short answer is "all TBB worker-threads and the main thread participate equally in task execution and stealing". There is a way of excluding the main thread, but usually this does not happen (and it generally should not). So whenever you start a parallel_for algorithm (for instance) to work on your data you should expect that all threads from the thread pool will start sharing the work on processing the data. If there is an error (an incorrect result of data processing, for example) it does not mean that there is one single thread to blame. Tasks are being distributed (shared via stealing) randomly and any thread can become responsible for doing the "wrong thing". I'd say in that case you'd need a debugger with "data breakpoint" capabilities, where you can set a breakpoint to a certain change of your data, which corresponds to the faulty behaviour. Intel Parallel Debugger might be a good choice, since it now supports "data breakpoints" and supports debugging of multi-threaded applications. Another choice would be to look at your application through Thread Checker. TBB supports Thread Checker and while you will not see any TBB internals being analyzed, you might be shown a couple of data-race diagnostics in your parallel_for Body object. Data-races are often the problem that cause unreproducible incorrect results of a multi-threaded application run. Watch out for those!
A different case would be, when in addition to TBB worker-threads you yourself create native threads using TBB wrapper. In that case the error would not be happening inside parallel_for and you will have to analyze what that additional thread was doing that was so incorrect. Since this is a native thread you still could use Intel Parallel Debugger.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Intel Parallel Debugger might be a good choice, since it now supports "data breakpoints" and supports debugging of multi-threaded applications.
I understand that Intel Parallel Debugger is Intel product, and you are working for Intel, but... hmm... Intel Parallel Debugger integrates into MSVC and MSVC has data breakpoints for years... do you mean some more advanced features of Intel Parallel Debugger?..
The other way to get "data breakpoint" functionality (provided that you have access to source code) is to instrument code manually:
void my_task::execute()
{
...
if (m_data == 13 and x == 666)
__asm int 3; // or __debugbreak() or __asm ("int 3") or whatever
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I understand that Intel Parallel Debugger is Intel product, and you are working for Intel, but... hmm... Intel Parallel Debugger integrates into MSVC and MSVC has data breakpoints for years... do you mean some more advanced features of Intel Parallel Debugger?..
The other way to get "data breakpoint" functionality (provided that you have access to source code) is to instrument code manually:
void my_task::execute()
{
...
if (m_data == 13 and x == 666)
__asm int 3; // or __debugbreak() or __asm ("int 3") or whatever
}
You probably do not want to insert an int03, rather you may want to create and insert your own _ASSERT and then place your break point within the function dispatched to by the _ASSERT (the whole application has but one point break on assertions). You also want the assert handler to throw up a message box or some other means of notification should you forget to insert the break point. Also, write the assert handler such that you can set the next statement for execution to a location that will return (as opposed to aborting the app). This way you can have a better chance of figuring out the problem (or stepping past the problem while trying to figure it out).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
a short answer is "all TBB worker-threads and the main thread participate equally in task execution and stealing". There is a way of excluding the main thread, but usually this does not happen (and it generally should not). So whenever you start a parallel_for algorithm (for instance) to work on your data you should expect that all threads from the thread pool will start sharing the work on processing the data. If there is an error (an incorrect result of data processing, for example) it does not mean that there is one single thread to blame. Tasks are being distributed (shared via stealing) randomly and any thread can become responsible for doing the "wrong thing". I'd say in that case you'd need a debugger with "data breakpoint" capabilities, where you can set a breakpoint to a certain change of your data, which corresponds to the faulty behaviour. Intel Parallel Debugger might be a good choice, since it now supports "data breakpoints" and supports debugging of multi-threaded applications. Another choice would be to look at your application through Thread Checker. TBB supports Thread Checker and while you will not see any TBB internals being analyzed, you might be shown a couple of data-race diagnostics in your parallel_for Body object. Data-races are often the problem that cause unreproducible incorrect results of a multi-threaded application run. Watch out for those!
A different case would be, when in addition to TBB worker-threads you yourself create native threads using TBB wrapper. In that case the error would not be happening inside parallel_for and you will have to analyze what that additional thread was doing that was so incorrect. Since this is a native thread you still could use Intel Parallel Debugger.
Do you mean "Intel Parallel Debugger" for MPI program debugging?
If YES, could you help me with it's link and EVAL version if any for Linux x86_64?
~BR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you mean "Intel Parallel Debugger" for MPI program debugging?
If YES, could you help me with it's link and EVAL version if any for Linux x86_64?
~BR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think Intel should also address -
(a) How soon a Intel ParallelStudio be made available for Linux x86_64 machine?
(b) Intel had brought tools related with HPC like - VTune, Thread Profiler, Thread Checker & Analyzer, IMB, ICC-v11.0, ISV, Intel-MPI; but Intel doesn't have tools which can debug MPI programs. How soon Intel can bring some debugger for MPI programming?
~BR
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think Intel should also address -
(a) How soon a Intel ParallelStudio be made available for Linux x86_64 machine?
(b) Intel had brought tools related with HPC like - VTune, Thread Profiler, Thread Checker & Analyzer, IMB, ICC-v11.0, ISV, Intel-MPI; but Intel doesn't have tools which can debug MPI programs. How soon Intel can bring some debugger for MPI programming?
~BR
Hi,
parallel debugging capabilities in the Linux debugger (with a completely new designed GUI) will be available in the next release of the Intel Compilers, expected for end of Q2. I will send you an invitation by email so you can sign up for the Beta if you'd like to try it. In this product you will also find MPI debugging capabilities.
Regards, Thomas
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page