I am trying to run the inspector on a game that uses about 200-300 MB of RAM. I run the inspxe-cl -collect ti1 . The inspector runs very slow on such a large application which I expected, but it seems that once my game and the inspector use up all my 2GB memory, the game becomes non responsive, that is it will either freeze or each click of the mouse will take 5 min to register. Once everything is so slow, it is impossible to interact with the game in order to cause possible deadlocks.
Is there anything that I can do so that such a large interactive application can be analyzed for deadlocks or data races with the Intel Inspector?
- Development Tools
- Intel® Inspector
- Parallel Computing
I will add some more ram as a start. Also is it possible to run the inspector only for a certain period of time or for some specific threads? Thus to avoid running it during the whole execution of the program?
As Peter said, the new Update of IXE reduces memory usage, which will help. It also improves the performance of our thread checking tools by about 3X, which will also help. If you are using an older version, that is one of the places that I would start.
Are there particular places in your code that are particularly interested (or not interested) in analyzing? Using -include or -exclude modules might help you to reduce the scope that is being analyzed, which will also help with time and space (you can find those functions on the project properties pane if you are using a GUI, or as a CLI option).
There are other options for improving performance at http://software.intel.com/en-us/articles/intel-inspector-xe-2013-controlling-analysis-cost
Looks like I should use the -include or -exclude commands. There are many shared libraries loaded at runtime that I do not need to inspect. I usually know which parts of the code need to be analyzed. I will give it a few more tries today and will let you know how it goes. And yes I am using the Update 9.
Thanks for the help!
I wanted to make sure that I am doing this right. After executing a command like this, it seems that the inspector is still loading and inspecting the libraries in the -module-filter-mode exclude. I am using a script to start my program, then I try to exclude all libriaries after module-filter. I separate them with a comma and I include the absolute paths as they are on my machine. The real command has more libraries that I try to exclude from being analyzed.
inspxe-cl -collect ti1 -module-filter-mode exclude -module-filter /path/to/ld-linux.so.2,/path/to/libGLU.so.1,/path/to/libboost_date_time.so.1.49.0,/path/to/libboost_filesystem.so.1.49.0 -appdebug=off -verbose -executable-of-interest myApp -- ./myAppScript
I am astonished that "exclude-filter" function doesn't work both in command line and GUI, Inspector XE Update 9.
# inspxe-cl -version
Intel(R) Inspector XE 2013 Update 9 (build 328075) Command Line tool
I selected example Tachyon_Insp come with the product to test.
# inspxe-cl -collect ti3 -module-filter-mode=exclude -module-filter=/lib64/libpthread.so.0,/usr/lib64/libstdc++.so.6 -- ./tachyon.find_and_fix_threading_errors
After data collecting, you can check r00?ti3/log/realtime_mode.log - it still loaded libstdc++.so.6 and libpthread.so.0
Create a new project for tachyon.find_and_fix_threading_errors, and select "exclude" mode and added libstdc++.so.6 & libpthread.so.0 - in project's properties dialog. Then run ti3, check "log" window, 2 libraries still were loaded. You also can get command line from GUI, such as
inspxe-cl -collect ti3 -knob terminate-on-deadlock=false -knob stack-depth=16 -knob scope=normal -knob remove-duplicates=true -knob use-maximum-resources=false -module-filter-mode=exclude -module-filter=/usr/lib64/libstdc++.so.6 -module-filter=/lib64/libpthread.so.0 -appdebug=off -app-working-dir /home/peter/tachyon_insp_xe -- /home/peter/tachyon_insp_xe/tachyon.find_and_fix_threading_errors
You will find excluded modules are not excluded. I have reported this to engineering, will update if any progress.
The dynamic analyzer still has to load the excluded modules, otherwise it could not run the application. But it does not have to instrument them, which is where the savings comes from. Being uninstrumented, there are no error generated from issues that happened in that module.
Inspector cannot detect memory peak, based on time stamp. However if you have interesting of knowing memory growth in specific code rang, you can use set-transition-start / set-transition-end, please see detail in helper.