Intel Inspector Optimization

Intel Inspector Optimization

Hi, 

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?

Thank you

S

 

12 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

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? 

Thanks

imagem de Peter Wang (Intel)

As I know, Inspector XE 2013 Update 9 will reduce memory consumption in target process' space.

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

Thanks.

 

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!

Stefan

Hi again, 

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

Any suggestions?

Thank you!

 

 

imagem de Peter Wang (Intel)

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.

1. CLI

# 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 

2. GUI

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.

Regards, Peter 

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.

Thanks for the info!

 

imagem de Peter Wang (Intel)

Sorry for misunderstandings and thanks to explanations from Holly. It's better that the tool shows loading info & instrumenting info separately, in my view. 

Hi All,

 How can I use inspector to detect memory peak as we used to do it in massif?

Thanks

Youcef

imagem de Peter Wang (Intel)

@ Youcef

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. 

Faça login para deixar um comentário.