VTune extremely slow

[rhl_]

Hi,

I am running the following:

$ which amplxe-gui
/opt/intel/vtune_amplifier_xe/bin64/amplxe-gui

On the following system:
$ cat /etc/redhat-release
Fedora release 15 (Lovelock)

$ uname -a
Linux torsion.******** 2.6.40.6-0.fc15.x86_64 #1 SMP Tue Oct 4 00:39:50 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

Here is the intel cpu model:
model name : Intel Xeon CPU 5160 @ 3.00GHz

And I have had a terrible time with this product. To be frank, VTune performs horribly.

I write Generic C++ code and compile with a standard *nix toolchain in Vim. I compile in 'debug' mode (meaning -g -02).

When I run VTune, no matter what type of analysis I run, it takes hours to display results. And once it finally displays those results, I usually cannot explore them, without it crashing. The product seems to want to display annoying flashy graphics at the expense of crashing the program.

Here is a screen capture of VTune running on my server, it was doing the 'hotspot' analysisr: http://imgur.com/5D5Mr

It has been running for an hour, and as you can see, I have not had any results. Here was some diagnostic output from my code:

$ amplxe-gui
File IO ...completed!
[... omitted due to irrelevance...]
total time (seconds): 84.48 (100%)

so my entire code took 84 seconds to run, i.e. not even 2 minutes of computation, and by the time I am doing describing this to you, vtune will be taking 1 hour to finish _displaying_ the results.

What is worse is that my experience is, if I leave this up long enough, (usually overnight), it eventually finishes, and then when I go to investigate the top down tree, (or anything else), if I click any gui item, eventually the program freezes again, or crashes, or does any number of bad things.

When I have gone to try and report bugs to you guys, It seems to get to real 'support' I have to pay for 'premier,' given the inferior quality of this product on my machine, why in gods name would I want to pay for it?

In short, how can I expect you guys to help me speed up my code, if your tools behave so poorly on my machines?

I would be discuss this in private with any intel software developer, to help diagnose and track down this issue.

[Mark_D_Intel]

Is the result directory stored over NFS or other networked file system? (The default location for storing the results is in a directory structure under the user's home directory)

If so, try collecting the results on a local disk. (Select 'Project Properties' in the GUI and choose "Store result in another directory")

Mark

[rhl_]

I am running it again like this, but if you look at the HTOP display, you can see that there is no going on (IORR = IOWR = 0)

[rhl_]

I followed your instructions, and when I got to the result display I got:

$ amplxe-gui
Segmentation fault (core dumped)

I can provide you with any other information you'd like.

[Peter_W_Intel]

Quoting rhl_

I followed your instructions, and when I got to the result display I got:

$ amplxe-gui
Segmentation fault (core dumped)

I can provide you with any other information you'd like.

"Segmentation fault" is very old story, and it has been fixed already.

Just want to know if you use latest buildUpdate 5?
$ amplxe-cl -version
Intel VTune Amplifier XE 2011 Update 5 (build 186533) Command Line Tool
Copyright (C) 2009-2011 Intel Corporation. All rights reserved.

If you still has this problem,enable "ulimit -c unlimited" to generate core dump file. This will be very helpful (using call stack info) to investigate the problem.

Regards, Peter

[rhl_]

It is not an old story.

$ amplxe-cl -version
Intel VTune Amplifier XE 2011 Update 5 (build 186533) Command Line Tool
Copyright (C) 2009-2011 Intel Corporation. All rights reserved.
$ ulimit -c unlimited
$ amplxe-gui
File IO ...completed!
complex filtration
balance ratio: 1
cover built
blowup built
Parallel: 55.0427
Serial: 5.25e-07
parallel betti (blowup):
2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Blowup factor: 1
filter complex: 3.14
build cover: 0.54 (0.91%)
build blowup: 1.67 (2.79%)
filter blowup: 2.58 (4.31%)
time for parallel_homology: 55.04 (91.99%)
total time: 59.84 (100%)
Segmentation fault (core dumped)

Here is the non-nfs directory I put this thing in:
$ ls /home/rhl/intel/segfault/
config.amplxeproj r000hs

just to demonstrate that /home is not network mounted:
$ cd
$ pwd
/net/grad/rhl

Do you guys have a formal bug tracker that I can open a bug in?

... you know if you guys released this code under the GPL, other people might be able to fix these issues.

[TimP]

Among easily encountered pitfalls may be:
collecting too many samples (set sample after values appropriate to the length of your run)
Default sampling rates attempt to be optimum for about the 20 second default time limit.
attempting to profile a case which is too big to accommodate additional overhead of VTune (memory, ....)

[rhl_]

Can you please explain further or point me at appropriate places in the documentation to read about this.

I am not sure where I was supposed to find out about these facts, before running the project...

If not setting these particular options more carefully has this affect, shouldn't the software be a bit more helpful in this regard. At least in _pointing out_ that such parameters exist...

[Peter_W_Intel]

Quoting rhl_

It is not an old story.

$ amplxe-cl -version
Intel VTune Amplifier XE 2011 Update 5 (build 186533) Command Line Tool
Copyright (C) 2009-2011 Intel Corporation. All rights reserved.
$ ulimit -c unlimited
$ amplxe-gui
File IO ...completed!
complex filtration
balance ratio: 1
cover built
blowup built
Parallel: 55.0427
Serial: 5.25e-07
parallel betti (blowup):
2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Blowup factor: 1
filter complex: 3.14
build cover: 0.54 (0.91%)
build blowup: 1.67 (2.79%)
filter blowup: 2.58 (4.31%)
time for parallel_homology: 55.04 (91.99%)
total time: 59.84 (100%)
Segmentation fault (core dumped)

Here is the non-nfs directory I put this thing in:
$ ls /home/rhl/intel/segfault/
config.amplxeproj r000hs

just to demonstrate that /home is not network mounted:
$ cd
$ pwd
/net/grad/rhl

Do you guys have a formal bug tracker that I can open a bug in?

... you know if you guys released this code under the GPL, other people might be able to fix these issues.

Have you seen a core file like core.xxxx generated?

You might go https://premier.intel.comto submit a ticket, with core file. If the core file is too big to be attached (>10MB), instead of using "gdb -c corefile amplxe-gui", then run "bt" command in gdb to retrieve call stack info - please add these info with the ticket. So we can use Intel Premier to track this problem.

Regards, Peter