GPU621/Intel Parallel Studio Inspector

From CDOT Wiki
Revision as of 15:24, 27 November 2020 by Hermanlu (talk | contribs)
Jump to: navigation, search


Group Members

1. Yuhao Lu

2. Song Zeng

3. Jiawei Yang

Intel Parallel Studio Inspector



Features and Functionalities

For further information, please refer to the official site of Intel Inspector. Intel Inspector is available as a stand-alone debugger as well as part of the Parallel Studio XE. Intel Inspector is designed to save money, time, data, and effort in developing applications. It is a convenient tool for solving memory, threading, and persistent memory errors of an application.




  • OpenMP
  • TBB
  • Parallel language extensions for the Intel C++ Compiler
  • Microsoft PPL
  • Win32 and POSIX threads
  • Intel MPI Library




Correctness Analyzer & Debugger


Memory Debugger


Threading Debugger



How to use









On-Demand Memory Analysis

Intel Inspector offers on-demand memory analysis to help developers save time on debugging memory problems. Memory analysis is very expensive and takes a lot of time. With the on-demand analysis, a developer can specify a portion of the execution time of the application to minimize the overhead created by memory analysis. The on-demand analysis focuses on memory growth detection and memory leak analysis.


For more details, please refer to this video by Intel

Memory problems

Memory Leak


int main()
	int* c;
	c = new int(5); //requests heap memory which will not be freed

	return 0;




Invalid Memory Access

A special program is used as an example in this section. The inspection on the TBB parallel_for workshop perfectly demonstrates the compatibility of Intel Inspector towards Threading Building Blocks algorithm.

#ifndef WORDCOUNT_H_
#define WORDCOUNT_H_

#include <tbb/tbb.h>

typedef bool (*Delimiter)(char);

class WordCount {
	const char* string;
	int* const stringSize;
	int* const numberOfWord;
	int number;
	Delimiter delimiter;

		string = str;
		number = numChar;
		delimiter = del;

		for (auto i = r.begin(); i != r.end(); i++) { // the loop only stops when i exactly equals to r.end()
			if (!delimiter(string[i])) {
				int s = 0;
				stringSize[i] = s;
				int n = 0;
					bool bad = false;
					for (int k = 0;
							bad = true;
				numberOfWord[i] = n;
			else {
				stringSize[i] = 0;
				numberOfWord[i] = 0;

Inspection result


The Intel Inspector locates the error that comes from the loop inside the functor used by the tbb::parallel_for() function. All the references of the location being illegally accessing are marked as errors, which indicates the error happens during a specific iteration of the loop. However, this inspection has an extremely high memory overhead which makes the analysis time a thousand times longer than the normal run.

Memory Growth

In application development, unexpected memory growth causes a lot of problems and it is very hard to locate since for most of the time it is not considered an error. By using Intel Inspector, we can quickly locate all potential lines that may be the cause of memory growth.

#include <iostream>
#include <vector>
#include <thread>

class PlaceHolder {
   int array[10000]{10};

int main()
   int n = 1000;
   std::vector<PlaceHolder> collection;
      collection.push_back(PlaceHolder()); //keep allocating heap memory

   return 0;



Thread problems

Race Condition


int main()
#include <iostream>
#include <thread>
#include <vector>

class Wallet {
	int mMoney;
	Wallet() :mMoney(0) {}
	int getMoney() {
		return mMoney;
	void addMoney(int money) {
		mMoney += money;

int testMultithreadWallet() {
	Wallet wallet;
	int threadNum = 5;
	std::vector<std::thread> threads;
	//Create 5 threads and push to the vector
			//Create a thread and run its lamda function
	//Join all threads back to main thread
	return wallet.getMoney();

int main() {
	int result = 0;
	return 0;

Incorrect results generated by the race condition code.

RaceResult1.jpg RaceResult2.jpg

Inspection summary by Intel Inspector


Using Intel Inspector, data race is quickly detected and located.




#include <iostream>
#include <mutex>
#include <thread>

using namespace std;
const int SIZE = 10;

mutex  Mutex1, Mutex2;

void even_thread_print(int i)
   lock_guard<mutex> g1(Mutex1);
   lock_guard<mutex> g2(Mutex2);

void odd_thread_print(int i)
   lock_guard<mutex> g2(Mutex2);
   lock_guard<mutex> g1(Mutex1);

void print(int n)
      if (n % 2 == 0) {

   cout << endl;

int main()


   return 0;

Program Outputs (Correct output and encounters deadlock)

DeadLockNoIssue.jpg DeadLockWithIssue.jpg

Intel Inspector result



With the use of Intel Inspector, the deadlock is quickly detected and located. By tracing the call stack we know which locations in our source code produced the deadlock.









Update 7: Friday, Nov 20, 2020 - Minor fixes

Update 8: Wednesday, Nov 25, 2020 - Minor fixes