amplxe-cl -finalize hanging at 19%

amplxe-cl -finalize hanging at 19%

I bought VTune Amplifier XE 2013 today with the hope of using it to drill down into some performance issues we're having on Minecraft PC, after having trialled it and found it to be pretty solid with the "Hotspots" profiling option. However, it just doesn't seem to work at all when selecting "Hotspots, call counts, stacks and context switches".

Either VTune itself sits there claiming to be "analyzing" the results with the progress bar not moving a single pixel (I gave it over an hour), or when I attempt to use amplxe-cl -finalize -r r001ah from the command line, it sits at:

amplxe: Executing actions  0 %
amplxe: Warning: The result contains a lot of raw data. Finalization may take a long time to complete.
amplxe: Executing actions 19 % Loading '8064-33112.vtss' file

I understand that it may take a long time, but it hasn't budged from 19% for the past 15 minutes, so I can only presume that it just doesn't work.

This is rather unfortunate, as it means that I've paid $900 for a piece of software I effectively can't use. I'm even more dismayed by the anemic support given to someone who reported this exact issue back in late 2013 on this very forum, with no commitment from Intel to fixing this issue in the GUI version of VTune, only a suggestion to use amplxe-cl -finalize from the command line, which sadly doesn't seem to work in my case.

How can I get this issue resolved?

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

After about 15 minutes it seems to have ticked over to 20%. Hopefully I don't have to wait 20 more hours (15 minutes * 80%) for it to finish finalizing the results, because after this amount of time it's already so slow as to be unusable. Is there any secret for making it faster other than omitting more data from my profiling?

Yes, it's important to set the sampling rates consistent with the sample run time; maybe reducing sample rate further if running many threads.  The crude way is by the expected run time you set in the Advanced setup, interpreting that as the expected total run time among the threads.

I haven't been successful myself with all those selections; you may have to experiment to find out which are useful for you.

MrAnderson (Intel)'s picture

Hi Ryan H:

Yes, for how long did you collect data?  There is an option to specify the approximate run time of your application.  It appears you are using the command line, so that option is -target-duration-type, where veryshort, short, medium, and long correspond to the project properties "Duration time estimate" values of "under 1 minute", "between 1 and 15 miuntes", "between 15 minutes and 3 hours", and "over 3 ours."

You might also consider using the User APIs __itt_pause() and __itt_resume() to only collection profiling data in the concerned areas.

Regards, MrAnderson
MrAnderson (Intel)'s picture

Oh, one more thing!  Don't store the results or the app on an NFS drive.  See this article for more details.

Regards, MrAnderson
iliyapolak's picture

 

@Ryan

During the finalizing phase can you use Process Explorer to monitor the progress.This can give a crude estimation in which thread the finalizing process is stuck.

iliyapolak's picture

 

@Ryan

Sorry forgotten to ask.Do you have Windows?

Login to leave a comment.