Error 0x4000001e in Intel Advisor XE: Can not load raw collector data - intel-parallel-studio

I'm using Intel Advisor XE, part of Parallel Studio XE 2013 with Ubuntu 2014. Program for Prime number is as:
#include "stdio.h"
#include "stdlib.h"
int isPrime(long unsigned int x)
{
long unsigned int i;
for (i = 2; i < x; i += 1)
{
if(x%i==0)
return 0;
}
if(i==x)
return i;
}
int main (int argc, char *argv[])
{
double tic=omp_get_wtime();
long unsigned int i,num;
num=999999;
for (i = 1; i <= num; i += 1)
{
if(isPrime(i)) printf("\t%lu",i);
}
return 0;
}
I run this program with both icc and gcc and tested it on Intel Parallel Studio XE Advisor XE 2013. It went well with resulting hotspots and resultant tree like . Now when I added Annotation code something like
#include "stdio.h"
#include "stdlib.h"
#include "/opt/intel/advisor_xe_2013/include/advisor-annotate.h"
int isPrime(long unsigned int x)
{
long unsigned int i;
for (i = 2; i < x; i += 1)
{
if(x%i==0)
return 0;
}
if(i==x)
return i;
}
int main (int argc, char *argv[])
{
long unsigned int i,num;
num=999999;
ANNOTATE_SITE_BEGIN( MySite1 ); //Loop control statement to begin a parallel code region (parallel site).
for (i = 1; i <= num; i += 1)
{
ANNOTATE_ITERATION_TASK( MyTask1 ); // This annotation identifies an entire body as a task.
if(isPrime(i)) printf("\t%lu",i);
}
ANNOTATE_SITE_END(); // End the parallel code region, after task execution completes
return 0;
}
It gave me error like "Can not load row collector data."
I'm uploading images for the result. which seems like no errors but at last it shows like
Note 1 /proc/sys/kernel/yama/ptrace_scope has been updated to 0.
Note 2 I have set up LibPath LD_LIBRARY_PATH:/opt/intel/advisor_xe_2013/include
PS I tried for fibonacci of 6 digit number, and got the same result saying NO DATA

The problem was with compilation, I played around various options and tried using -I option with GCC and ICC to include library path, which I mentioned for header file, i.e. /opt/intel/advisor_xe_2013/include/ and also linked libraries using -ldl option which solved problem.

Related

How to emulate *really simple* variable bit shifts with SSE?

I have two variable bit-shifting code fragments that I want to SSE-vectorize by some means:
1) a = 1 << b (where b = 0..7 exactly), i.e. 0/1/2/3/4/5/6/7 -> 1/2/4/8/16/32/64/128/256
2) a = 1 << (8 * b) (where b = 0..7 exactly), i.e. 0/1/2/3/4/5/6/7 -> 1/0x100/0x10000/etc
OK, I know that AMD's XOP VPSHLQ would do this, as would AVX2's VPSHLQ. But my challenge here is whether this can be achieved on 'normal' (i.e. up to SSE4.2) SSE.
So, is there some funky SSE-family opcode sequence that will achieve the effect of either of these code fragments? These only need yield the listed output values for the specific input values (0-7).
Update: here's my attempt at 1), based on Peter Cordes' suggestion of using the floating point exponent to do simple variable bitshifting:
#include <stdint.h>
typedef union
{
int32_t i;
float f;
} uSpec;
void do_pow2(uint64_t *in_array, uint64_t *out_array, int num_loops)
{
uSpec u;
for (int i=0; i<num_loops; i++)
{
int32_t x = *(int32_t *)&in_array[i];
u.i = (127 + x) << 23;
int32_t r = (int32_t) u.f;
out_array[i] = r;
}
}

No Symbols Loaded: libmex.pdb not loaded (throw_segv_longjmp_seh_filter() = EXCEPTION_CONTINUE_SEARCH : C++ exception)

In order to create a MEX function and use it in my MATLAB code, like this:
[pow,index] = mx_minimum_power(A11,A12,A13,A22,A23,A33);
I've created the file mx_minimum_power.cpp and written the following code in it:
#include <math.h>
#include <complex>
#include "mex.h"
#include "matrix.h"
#include "cvm.h"
#include "blas.h"
#include "cfun.h"
using std::complex;
using namespace cvm;
/* The gateway function */
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
const int arraysize = 62172;
const int matrixDimention = 3;
float *inMatrixA11 = (float *)mxGetPr(prhs[0]);
complex<float> *inMatrixA12 = (complex<float> *)mxGetPr(prhs[1]);
complex<float> *inMatrixA13 = (complex<float> *)mxGetPr(prhs[2]);
float *inMatrixA22 = (float *)mxGetPr(prhs[3]);
complex<float> *inMatrixA23 = (complex<float> *)mxGetPr(prhs[4]);
float *inMatrixA33 = (float *)mxGetPr(prhs[5]);
basic_schmatrix< float, complex<float> > A(matrixDimention);
int i = 0;
for (i = 0; i < arraysize; i++)
{
A.set(1, 1, inMatrixA11[i]);
A.set(1, 2, inMatrixA12[i]);
A.set(1, 3, inMatrixA13[i]);
A.set(2, 2, inMatrixA22[i]);
A.set(2, 3, inMatrixA23[i]);
A.set(3, 3, inMatrixA33[i]);
}
}
And then in order to be able to debug the code, I've created the mx_minimum_power.pdb and mx_minimum_power.mexw64 files, using the following code in the Matlab Command Window:
mex -g mx_minimum_power.cpp cvm_em64t_debug.lib
The files blas.h, cfun.h, cvm.h and cvm_em64t_debug.lib are in the same directory as mx_minimum_power.cpp.
They are the headers and library files of the CVM Class Library.
Then I've attached MATLAB.exe to Visual Studio 2013, using the way explained here.
and have set a breakpoint at line40:
When I run my MATLAB code, there's no error until the specified line.
But if I click on the Step Over button, I'll encounter the following message:
With the following information added to the Output:
First-chance exception at 0x000007FEFCAE9E5D in MATLAB.exe: Microsoft C++ exception: cvm::cvmexception at memory location 0x0000000004022570.
> throw_segv_longjmp_seh_filter()
throw_segv_longjmp_seh_filter(): C++ exception
< throw_segv_longjmp_seh_filter() = EXCEPTION_CONTINUE_SEARCH
Can you suggest me why libmex.pdb is needed at that line and how should I solve the issue?
If I stop debugging, I'll get the following information in MATLAB Command Window:
Unexpected Standard exception from MEX file.
What() is:First index value 0 is out of [1,4) range
Right before pressing the step over button, we have the following values for A11[0],A12[0],A13[0],A22[0],A23[0],A33[0]:
that are just right as my expectations, according to what MATLAB passes to the MEX function:
Maybe the problem is because of wrong allocation for matrix A, it is as follows just before pressing the step over button.
The problem occurs because we have the following code in lines 48 to 53 of the cvm.h file:
// 5.7 0-based indexing
#if defined (CVM_ZERO_BASED)
# define CVM0 TINT_ZERO //!< Index base, 1 by default or 0 when \c CVM_ZERO_BASED is defined
#else
# define CVM0 TINT_ONE //!< Index base, 1 by default or 0 when \c CVM_ZERO_BASED is defined
#endif
That makes CVM0 = 1 by default. So if we press the Step Into(F11) button at the specified line two times, we will get into line 34883 of the file cvm.h:
basic_schmatrix& set(tint nRow, tint nCol, TC c) throw(cvmexception)
{
this->_set_at(nRow - CVM0, nCol - CVM0, c);
return *this;
}
Press Step Into(F11) at line this->_set_at(nRow - CVM0, nCol - CVM0, c); and you'll go to the definition of the function _set_at:
// sets both elements to keep matrix hermitian, checks ranges
// zero based
void _set_at(tint nRow, tint nCol, TC val) throw(cvmexception)
{
_check_lt_ge(CVM_OUTOFRANGE_LTGE1, nRow, CVM0, this->msize() + CVM0);
_check_lt_ge(CVM_OUTOFRANGE_LTGE2, nCol, CVM0, this->nsize() + CVM0);
if (nRow == nCol && _abs(val.imag()) > basic_cvmMachMin<TR>()) { // only reals on main diagonal
throw cvmexception(CVM_BREAKS_HERMITIANITY, "real number");
}
this->get()[this->ld() * nCol + nRow] = val;
if (nRow != nCol) {
this->get()[this->ld() * nRow + nCol] = _conjugate(val);
}
}
pressing Step Over(F10) button,you'll get the result:
so in order to get nRow=1 and nCol=1 and not nRow=0 and nCol=0, which is out of the range [1,4), you should write that line of code as:
A.set(2, 2, inMatrixA11[i]);

Unable to link external lib (CLAPACK) using MATLAB mex

I'm new to mex and this problem spent me days but I still cannot figure out what to do.
I create la_test.cpp file to test one of the subroutines in CLAPCK: cgemm_ (complex matrix-matrix multiplication). Here is the code:
#include "mex.h"
#include "matrix.h"
#include <string.h>
#include <stdlib.h>
#include <malloc.h>
#include <iostream>
#include <stdio.h>
#include "f2c.h"
#include "clapack.h"
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
float *Xr,*Xi; // To store the input data
float *zsr,*zsi; // To store the output
long int m,n;
complex *A;
Xr = (float *) mxGetPr(prhs[0]);
Xi = (float *) mxGetPi(prhs[0]);
size_t K = mxGetNumberOfDimensions(prhs[0]);
const int *size = mxGetDimensions(prhs[0]);
m = mxGetM(prhs[0]);
n = mxGetN(prhs[0]);
A = new complex[m*n];
complex one = {1.0f, 0.0f}, zero = {0.0f, 0.0f};
for (int i=0; i<m; i++){
for (int j=0; j<n; j++){
complex rc = {Xr[j + n*i], Xi[j + n*i]};
A[j + n*i] = rc;
}
}
plhs[0] =(mxArray *) mxCreateDoubleMatrix( n, n, mxCOMPLEX );
zsr = (float *) mxGetPr(plhs[0]);
zsi = (float *) mxGetPi(plhs[0]);
complex *AtA = 0;
AtA = new complex[n*n];
char *chn = "N";
char *chc = "C";
cgemm_(chc, chn, &n, &n, &m, &one, A, &m, A, &m, &zero, AtA, &n);
for (int i=0; i<m; i++){
for (int j=0; j<n; j++){
zsr[j + n*i] = AtA[j + n*i].r;
zsi[j + n*i] = AtA[j + n*i].i;
}
}
}
Basically, I store input matrix into A and try to compute A'*A. Header files: f2c.h, clapack.h as well as three 64bit libraries: blas.lib, libf2c.lib and lapack.lib from http://icl.eecs.utk.edu/lapack-for-windows/clapack/index.html#install are all in the same file of la_test.cpp. I'm working on Windows 7 64bit system with matlab r2013a and Visual Studio 2012.
I have tried with both:
mex la_test.cpp lapack.lib libf2c.lib blas.lib
and
mex -llapack -llibf2c -lblas -L"C:\Users\Ziwu\Desktop\la_test" la_test.cpp
all with following error:
Creating library C:\Users\Ziwu\AppData\Local\Temp\mex_epl230\templib.x and object C:\Users\Ziwu\AppData\Local\Temp\mex_epl230\templib.exp
la_test.obj : error LNK2019: unresolved external symbol cgemm_ referenced in function mexFunction
la_test.mexw64 : fatal error LNK1120: 1 unresolved externals
I've checked on Internet for long time, but found no solution yet!
Please help me if you have any advice.

Why is OpenMP in a mex file only producing 1 thread?

I am new to OpenMP. I have the following code which compiles fine using Matlab mex configured with MSVS2010. The computer has 8 processors available (which I checked also by using matlabpool).
#include "mex.h"
#include <omp.h>
typedef unsigned char uchar;
typedef unsigned int uint;
//Takes a uint8 input array and uint32 index array and preallocated uint8 array the same
//size as the first one and copies the data over using the indexed mapping
void mexFunction( int nlhs, mxArray *plhs[], int nrhs, const mxArray*prhs[] )
{
uint N = mxGetN(prhs[0]);
mexPrintf("n=%i\n", N); mexEvalString("drawnow");
uchar *input = (uchar*)mxGetData(prhs[0]);
uint *index = (uint*)mxGetData(prhs[1]);
uchar *output = (uchar*)mxGetData(prhs[2]);
uint nThreads, tid;
#pragma omp parallel private(tid) shared(input, index, output, N, nThreads) num_threads(8)
{
tid = omp_get_thread_num();
if (tid==0) {
nThreads = omp_get_num_threads();
}
for (int i=tid*N/nThreads;i<tid*N/nThreads+N/nThreads;i++){
output[i]=input[index[i]];
}
}
mexPrintf("nThreads = %i\n",nThreads);mexEvalString("drawnow");
}
The output I get is
n=600000000
nThreads = 1
Why is only one thread being created despite me requesting 8?
Sigh. Typical, spend hours trying and failing and then find the answer 5 minutes after posting to SO.
The file needs to be mexed with openmp support
mex mexIndexedCopy.cpp COMPFLAGS="/openmp $COMPFLAGS"

Fastest way of bitwise AND between two arrays on iPhone?

I have two image blocks stored as 1D arrays and have do the following bitwise AND operations among the elements of them.
int compare(unsigned char *a, int a_pitch,
unsigned char *b, int b_pitch, int a_lenx, int a_leny)
{
int overlap =0 ;
for(int y=0; y<a_leny; y++)
for(int x=0; x<a_lenx; x++)
{
if(a[x + y * a_pitch] & b[x+y*b_pitch])
overlap++ ;
}
return overlap ;
}
Actually, I have to do this job about 220,000 times, so it becomes very slow on iphone devices.
How could I accelerate this job on iPhone ?
I heard that NEON could be useful, but I'm not really familiar with it. In addition it seems that NEON doesn't have bitwise AND...
Option 1 - Work in the native width of your platform (it's faster to fetch 32-bits into a register and then do operations on that register than it is to fetch and compare data one byte at a time):
int compare(unsigned char *a, int a_pitch,
unsigned char *b, int b_pitch, int a_lenx, int a_leny)
{
int overlap = 0;
uint32_t* a_int = (uint32_t*)a;
uint32_t* b_int = (uint32_t*)b;
a_leny = a_leny / 4;
a_lenx = a_lenx / 4;
a_pitch = a_pitch / 4;
b_pitch = b_pitch / 4;
for(int y=0; y<a_leny_int; y++)
for(int x=0; x<a_lenx_int; x++)
{
uint32_t aVal = a_int[x + y * a_pitch_int];
uint32_t bVal = b_int[x+y*b_pitch_int];
if (aVal & 0xFF) & (bVal & 0xFF)
overlap++;
if ((aVal >> 8) & 0xFF) & ((bVal >> 8) & 0xFF)
overlap++;
if ((aVal >> 16) & 0xFF) & ((bVal >> 16) & 0xFF)
overlap++;
if ((aVal >> 24) & 0xFF) & ((bVal >> 24) & 0xFF)
overlap++;
}
return overlap ;
}
Option 2 - Use a heuristic to get an approximate result using fewer calculations (a good approach if the absolute difference between 101 overlaps and 100 overlaps is not important to your application):
int compare(unsigned char *a, int a_pitch,
unsigned char *b, int b_pitch, int a_lenx, int a_leny)
{
int overlap =0 ;
for(int y=0; y<a_leny; y+= 10)
for(int x=0; x<a_lenx; x+= 10)
{
//we compare 1% of all the pixels, and use that as the result
if(a[x + y * a_pitch] & b[x+y*b_pitch])
overlap++ ;
}
return overlap * 100;
}
Option 3 - Rewrite your function in inline assembly code. You're on your own for this one.
Your code is Rambo for the CPU - its worst nightmare :
byte access. Like aroth mentioned, ARM is VERY slow reading bytes from memory
random access. Two absolutely unnecessary multiply/add operations in addition to the already steep performance penalty by its nature.
Simply put, everything is wrong that can be wrong.
Don't call me rude. Let me be your angel instead.
First, I'll provide you a working NEON version. Then an optimized C version showing you exactly what you did wrong.
Just give me some time. I have to go to bed right now, and I have an important meeting tomorrow.
Why don't you learn ARM assembly? It's much easier and useful than x86 assembly.
It will also improve your C programming capabilities by a huge step.
Strongly recommended
cya
==============================================================================
Ok, here is an optimized version written in C with ARM assembly in mind.
Please note that both the pitches AND a_lenx have to be multiples of 4. Otherwise, it won't work properly.
There isn't much room left for optimizations with ARM assembly upon this version. (NEON is a different story - coming soon)
Take a careful look at how to handle variable declarations, loop, memory access, and AND operations.
And make sure that this function runs in ARM mode and not Thumb for best results.
unsigned int compare(unsigned int *a, unsigned int a_pitch,
unsigned int *b, unsigned int b_pitch, unsigned int a_lenx, unsigned int a_leny)
{
unsigned int overlap =0;
unsigned int a_gap = (a_pitch - a_lenx)>>2;
unsigned int b_gap = (b_pitch - a_lenx)>>2;
unsigned int aval, bval, xcount;
do
{
xcount = (a_lenx>>2);
do
{
aval = *a++;
// ldr aval, [a], #4
bval = *b++;
// ldr bavl, [b], #4
aval &= bval;
// and aval, aval, bval
if (aval & 0x000000ff) overlap += 1;
// tst aval, #0x000000ff
// addne overlap, overlap, #1
if (aval & 0x0000ff00) overlap += 1;
// tst aval, #0x0000ff00
// addne overlap, overlap, #1
if (aval & 0x00ff0000) overlap += 1;
// tst aval, #0x00ff0000
// addne overlap, overlap, #1
if (aval & 0xff000000) overlap += 1;
// tst aval, #0xff000000
// addne overlap, overlap, #1
} while (--xcount);
a += a_gap;
b += b_gap;
} while (--a_leny);
return overlap;
}
First of all, why the double loop? You can do it with a single loop and a couple of pointers.
Also, you don't need to calculate x+y*pitch for every single pixel; just increment two pointers by one. Incrementing by one is a lot faster than x+y*pitch.
Why exactly do you need to perform this operation? I would make sure there are no high-level optimizations/changes available before looking into a low-level solution like NEON.