Can VTune be used to profile a massively multi-threaded application?

[haroldz]

Hi,

I am working on an multimedia application that involves massive number (hundreds) of threads. I have downloaded an evaluation copy of VTune, but found it NOT suitable to my application:

1. When I run either sampling or call-graph, it typically gave a result of 200-600 threads from my app proces alone.

2. In both sampling and call-graph view, I can't filter these threads by "accessed certain module" to quickly find the threads that I am interested.

3. In call graph, I can't sort the threads by "self-time" or "total-time" (sorting by those criteria only applies to functions inside one thread)

4. Sampling and call-graph can't be executed in the same run (to keep thread ID unchanged), so when I find a "hot" thread in sampling view, I could not got details from call-graph.

5. In call-graph, I could not find a good indication of "real processing time" for the threads (I have tried "total time", "self time" "wait time" etc, but all seems to identify those threads that started first, but actually were in waiting mode most of time, as "red-orange" threads) But one of my main processing thread is always in grey color..

Are these real limitations of VTune, or did I miss something?

Thanks for your response

Harold

[Daniel_B_Intel2]

Hi Harold,

Your notes are very interesting. Please see my comments inside your post.
-Daniel

> Hi,
>
> I am working on an multimedia application that
> involves massive number (hundreds) of threads. I
> have downloaded an evaluation copy of VTune, but
> found it NOT suitable to my application:
>
> 1. When I run either sampling or call-graph, it
> typically gave a result of 200-600 threads from my
> app proces alone.
Do you mean that the real number of threads is bigger then one reported by VTune? Are you sure that this (bigger) number of threads are really produced during the "duration time" you are running the sample collection for example?
Personally, I am not aware of any limitation of # of threads in VTune. The reported threads are those where at least one "sample" for the particular event was recorded. Probably the threads that were not reported were too short time in CPU and no "sample" fall on it.


>
> 2. In both sampling and call-graph view, I can't
> filter these threads by "accessed certain module" to
> quickly find the threads that I am interested.

I was under impression that at least in "sampling view" this is possible: in "Modules" view (press Modules button) mark a particular module, then in "Thread view" (Press thread button) you'd see the threads that used the marked module.

>
> 3. In call graph, I can't sort the threads by
> "self-time" or "total-time" (sorting by those
> criteria only applies to functions inside one
> thread)
Good point to submit to Intel's Premier support as an enhancement request.

>
> 4. Sampling and call-graph can't be executed in the
> same run (to keep thread ID unchanged), so when I
> find a "hot" thread in sampling view, I could not got
> details from call-graph.
Actually the results of such simultaneous collection will not reflect the real program run. Sampling will report events connected to running of "instrumented" application. (with all stuff added to produce call graph)

>
> 5. In call-graph, I could not find a good indication
> of "real processing time" for the threads (I have
> tried "total time", "self time" "wait time" etc, but
> all seems to identify those threads that started
> first, but actually were in waiting mode most of
> time, as "red-orange" threads) But one of my main
> processing thread is always in grey color..
Sampling collection is devoted to report on "real" times (when you collect "clockticks events") in ring 3 and 0 etc. Call graph should show the program flow and the way (functions chain) you get to the particular function of interest

>
> Are these real limitations of VTune, or did I miss
> something?
>
> Thanks for your response
>
> Harold