Binary compiled under Windows 7, VS2010, and Intel Fortran 12.1, using open MP. This binary works fine in Debug mode under VS. However, when I switch to Amplifier it give this message. Amplifier is inheriting the settings from the VS project. There is a very brief command window that flashes up, but too fast for me to read. There is no output on the output file of the code. In Debug the code immediately writes MCNP6 in block letters - I get nothing under Amplifier.
When executing under Debug or Amplifier I use the following input to the command:
tasks 1 name=input.inp outp=output.out xsdir=xsdir_mcnp6.1_endfb-7.1 srctp=srctp
Tasks 1 means the threading is not used.
The code has some irritating features - it is a F66 upgrade that has some data misalignments and linkage issues that require the /FORCE parameter to be used in linking. But, it works fine regardless all over the world in LINUX, MacOS and Windows environments. I have run cases that executed for 3 days using an I7-5960 extreme overclocked to 3.8 GHz and all threads. It has some serious foot-draggers disease that I am trying to diagnose with Amplifier - without success so far.
This code is heavily restricted by US Government regulations that prevent sending it (275,00 lines of code) anywhere.
Small sample FORTRAN codes work just fine.
If Amplifier could just tell me what is not liked I could do something about it. Suggestions, please.
I don't know what version of amplifier you used...current product is VTune(TM) Amplifier XE 2016 U3...and VS2010 will not be supported (I mean to use amplifier in VS integration, at least you should use VS2012 or later), but binary built with Intel Fortran 12.1 should be supported I think. I suggest to profile your binary in cmd which can run your program (which runs 3 days?? This is too long and too big to generate result file by amplifier, please profile performance data in piece of code of your interest). For example -
Open a cmd with administrator, run amplxe-vars.sh under amplifier directory.
cd working directory and run your application ; get process id via taskmgr.exe
>amplxe-cl -c general-exploration -start-paused -target-pid PID -r r001ge
You can open another cmd with administrator, run amplxe-vars.sh as well...cd same working directory as previous cmd.
>amplxe-cl -c command resume -r r001ge ; you like to profile for critical code area
>amplxe-cl -c command stop -r r001ge; terminate collector to generate result.
Does it happen if you use Advanced Hotspots analysis type within VS? In this case VTune uses system APIs only to execute the binary.
Can you check ability to do analysis from command line? Like:
1) open command line, verify that you can launch your application
2) execute the following command:
<VTune install dir>/bin64/amplxe-cl -c advanced-hotspots <your application and parameters>
Does it execute your app?
Peter and Vitaly,
Thanks for the suggestion. It worked. After the collection I doube clicked the results and analyzed the problem - which is not solved. I reduced the 1 hour delay to 1 minute ! Many thanks.
correction - is NOW solved. We theorized about what this was being caused by - and now we know. It is a poorly defined sort routine. Simple sorts are for simple cases - not for real world problems.
Peter - follow-up question. I have now identified a problem in the beginning of code execution, and fixed it. Now there is another - it occurs after about an hour of processing on a really fast I7. Is it possible to start/stop data collection by using breakpoints?
@ Morgan L
> Is it possible to start/stop data collection by using breakpoints?
You can use(insert) Resume/Pause API in your critical code to collect to identify the problem, instead of using "amplxe-cl -command resume|pause", you also can use option "-duration N" to stop collection.
You can find contents of helper - https://software.intel.com/en-us/node/605577, see Collection Control API, with examples.
You also can use command line like "amplxe-cl -c advanced-hotspots -start-paused -d 120 -- application"