I saw some Intel announcements about APS Application Performance Snapshot and seemed worth trying out to find performance issues with our in house code base. It is 600 K lines, 14 executables, runs on windows (finally x64!!) and Linux (double !!). Windows builds in MS visual studio 2015 and Intel Fortran and C 17.1. I read somewhere I should compile with usual release optimization but add /debug to compile/link. I build the debug version for reference and ran it in visual studio no problems. running the x64 windows release (with /debug) inside the aps bat script, I got access violations. Ye ole adding a print statement nearby got past one access violation, then another, then another,... So I tried running the debug build (x64 Debug) under aps and got another access violation even though it had run in the VS debugger. Next I ran the same debug exe as I had run under aps.bat and just removed the aps.bat to run the exe alone. Its running fine. I am not expecting a fix since I can't share the source. Just sharing what my first experience with APS was. I will likely repeat the process on Linux with version 17.1. Not that I would turn down suggestions.
I also tried Linux. I have an error about loading
ERROR: ld.so: object '/pw/test/linux/intel/Compiler/17.0.5/vtune_amplifier_xe_2017.5.0.526192/lib64/libmps.so' from LD_PRELOAD cannot be preloaded: ignored.
My exe is a static build; maybe that is why, but it seems to have run anyway.
/pw/test/linux/intel/Compiler/17.0.5/vtune_amplifier_xe_2017/bin64/aps.sh /pw/data/DDS/m313133/acsys/v_test2/bin/linux/Release/acsysrun.exe -b -i batch.mac >batch2.log
in the log file, I see:
| Summary information
Application : v599
What I don't understand is the Application printed above: v599. My command with aps runs an exe named acsysrun.exe, not v599. acsysrun does multiple call system() to run other executables including Ansys, one of which is named v599. v599 was not compiled specifically for APS. So if I launched acsysrun and it called multiple separate exe's via call system(), am I seeing the performace summary for acsysrun or as the line
Application : v599
seems to indicate, for the v599.exe, or for all the processes run directly or indirectly (system call from acsysrun)?
I need help from intel for APS. I can’t tell what the tool is reporting. I know this is not really a helpdesk, but going through our official channels for me to get Intel support for this is just going to take a really long time.
The question is I run the APS Linux script for executable proc0.exe.
Proc0.exe is a Fortran code which has call system to procA.exe, procB.exe, procC.exe.
The APS summary says the application name is procC, not proc0.
Are the reported statistics from procC? Or are they proc0 even though it says procC? Or is it proc0 and all call system called exe’s?
if anyone could help explain what APS is really doing, it would be much appreciated.
intel fortran and C 17.1. on Linux.
I had never heard of APS until I saw your post. You may have better chances of receiving responses if you post in the appropriate forum: https://software.intel.com/en-us/forums/intel-performance-snapshot .
If I build my ifort application in debug mode on windows, and it runs successfully in visual studio and just running the executable from the command line, but when I run the same executable inside the APS script (aps.bat) and it crashes with an exception violation, is this a problem for the intel fortran compiler team or the intel APS performance tool team? It does run on Linux, even if I don't know what it is reporting on.
I put something on the APS user forum but have not (yet) gotten any response.
When you said it runs in debug mode, does that mean with full run-time checking enabled?
I ask because this sort of symptom sorta sounds like an uninitialized variable, or writing out-of-bounds, or any other sort of illegal memory access behavior.
If, as Lorri points out, your code is not fully debugged, it is probably not a good idea to run it through code profilers and performance analyzers of any kind, because you will risk reaching wrong conclusions.
For example, let us say that your code contains a time-consuming loop, and that the loop count is not properly defined. It could happen that when you choose not to optimize (option /Od) the loop will run 127 times, whereas with /fast the loop will run 31767 times. If you do not detect any errors in the output or behavior of the program, you might conclude that optimization slowed the program or that you have discovered an optimizer bug, etc.