Device not available error when running code on Intel MIC - intel-mic

When I try to run my code on Intel MIC it is giving an error like
"offload error: cannot offload to MIC - device is not available"
My sample code is
#include <stdio.h>
#include <omp.h>
int main()
{
int N=10;
int i, a[N];
#pragma offload target(mic)
#pragma omp parallel
#pragma omp for
for(i = 0; i < N; i++)
{
a[i]=i;
printf("a[%d] :: %d \n", i, a[i]);
printf(".....................:\n\n");
}
return 0;
}

One of 2 things is happening. Either the card is not booted, you can check this by:
sudo micctrl -s
Or the runtime cannot find dependent libraries. This is most likely due to not sourcing the compiler environment variables:
source /opt/intel/composerxe/bin/compilervars.sh intel64

I believe you have not set up the compiler's environment.
Compiler Environment:
source /opt/intel/composerxe/bin/compilervars.sh intel64
Also set the offload library as well.
#include "offload.h"

Related

warning #3180: unrecognized OpenMP #pragma

I am having a really hard time in implementing openMP code on my mac machine on Terminal with icc compiler. I find the following error! Please do help me with the correction of error.
The following code is pasted as follows. IT NEVER WORK FOR openMP for, reduce either. The pragma is just not recognising. Appreciate yourself trying the code to help.
#include <stdio.h>
#include <omp.h>
int main()
{
#pragma omp parallel for
{
for(int i=0;i<3;i++)
{
printf("Hello");
}
}
return 0;
}
To add to my comment, the correct version of the code is
#include <stdio.h>
#include <omp.h>
int main()
{
#pragma omp parallel for
for(int i=0;i<3;i++)
{
printf("Hello");
}
return 0;
}
The proper compiler command line is icc -fopenmp ... -o bla.exe bla.c (assuming that the file is named bla.c). Please replace ... with the other command line options that you will need for your code to compile.
UPDATE: The proper compiler command line for the new OpenMP compilers from Intel is to use -fiopenmp (needs -fopenmp-targets=spir64 for GPUs).

G++ -cilkplus random behavior with std::vectors

The following (reduced) code is very badly handled by the series of GCC
#include <vector>
#include <cilk/cilk.h>
void walk(std::vector<int> v, int bnd, unsigned size) {
if (v.size() < size)
for (int i=0; i<bnd; i++) {
std::vector<int> vnew(v);
vnew.push_back(i);
cilk_spawn walk(vnew, bnd, size);
}
}
int main(int argc, char **argv) {
std::vector<int> v{};
walk(v , 5, 5);
}
Specifically:
G++ 5.3.1 crash:
red.cpp: In function ‘<built-in>’:
red.cpp:20:39: internal compiler error: in lower_stmt, at gimple-low.c:397
cilk_spawn walk(vnew, bnd, size);
G++ 6.3.1 create a code which works perfectly well if executed on one core
but segfault sometime, signal a double free some other times if using more cores. A student who
has a arch linux g++7 reported a similar result.
My question : is there something wrong with that code. Am I invoking some
undefined behavior or is it simply a bug I should report ?
Answering my own question:
According to https://gcc.gnu.org/ml/gcc-help/2017-03/msg00078.html its indeed a bug in GCC. The temporary is destroyed in the parent and not in the children in a cilk_spawn. So if the thread fork really occur, it might be destroyed too early.

How do I use boost library with WDK environment

I wanna to compile my c plus plus project that using boost library with WDK rather than VisualStudio.
My computer's OS is Windows7-64bit, the WDK version is 7.6 and boost library version is 1.51
Once I compile my source code project, the WDK compiler will occure an error:
e:\lib\boost_1_51_0\boost\array.hpp(72) : error C2039: 'ptrdiff_t' : is not a member of 'std' .
Whole project's file contents are as follow:
File sources:
TARGETTYPE=PROGRAM
TARGETNAME=helloworld
UMENTRY=main
USE_MSVCRT=1
USE_NATIVE_EH=1
#
# use iostream package and STL
#
USE_IOSTREAM=1
USE_STL=1
STL_VER=70
#
# my boost library root directory
#
BOOST_INC_PATH=E:\lib\boost_1_51_0
INCLUDES=$(BOOST_INC_PATH)
TARGETLIBS=$(SDK_LIB_PATH)\user32.lib
SOURCES=HelloWorld.cpp
UMTYPE=console
UMBASE=0x4000000
File HelloWorld.cpp:
#include <iostream>
#include <vector>
#include <string>
#include <boost/array.hpp>
void InvokeVector()
{
//invoke STL's vector
std::vector<std::string> vec;
vec.push_back("Entry ");
vec.push_back("of ");
vec.push_back("Vector");
vec.push_back("……\n");
//print vec
for (int i=0; i<vec.size(); i++) {
std::cout<<vec.at(i);
}
}
void InvokeBoost()
{
//invoke Boost's array<T, N>
boost::array<int, 3> arr = {1, 2, 3};
for (int i=0; i<arr.size(); i++) {
std::cout<<"arr["<<i<<"]"<<"is" <<arr[i]<<std::endl;
}
}
int main()
{
// InvokeVector(); //run normally
InvokeBoost(); //it will occure an error
return 0;
}
Could you please teach me how to solve this problem? Any help will be greatly appreciated!
Short answer: No.
But you can port some.
It's well explained here : The NT Insider:Guest Article: C++ in an NT Driver
One of the main problems with C++ in the
kernel is that most of the "nice" features of the language are not
directly available in that mode. Some are easy to recreate and we will
see how to do that. However, some features should be forgotten such as
C++ exceptions, which are not the same as kernel exceptions.
Such features have to be forgotten simply because there is no support
for them in kernel mode. Translation: does not compile. If you have
the time and energy you may attempt to port them to kernel mode, but
frankly, exceptions are too slow for kernel mode. This will have an
impact on your C++ coding style, which is something you should keep in
mind.
longer answer - yes
just add
typedef int ptrdiff_t;
before pulling in boost headers and all will be well for basic boostness

sys/wait.h and sys/kthread.h do not compile together

I am compiling a kernel module in linux related to creating kthreads to achieve parallelism but I am stuck at compiling issues.
Here is my code:
#include <linux/init.h>
#include <linux/errno.h>
#include <asm/byteorder.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/kthread.h>
#include <linux/types.h>
#include <sys/wait.h>
void threadfn1()
{
int j;
for( j = 0; j < 1000000; j++ )
printk(KERN_INFO "I AM THREAD 1 %d\n",j);
}
void threadfn2()
{
int j;
for( j = 0; j < 1000000; j++ )
printk(KERN_INFO "I AM THREAD 2 %d\n",j);
}
static int __init abc_init(void)
{
struct task_struct *t1 = kthread_run(threadfn1, NULL, "thread1");
struct task_struct *t2 = kthread_run(threadfn2, NULL, "thread2");
printk(KERN_INFO "HELLO WORLD\n");
waitpid(-1,NULL,0); // whatever the parameters of waitpid() are
}
static void __exit abc_fini(void)
{
printk(KERN_INFO "BYE WORLD\n");
}
module_init(abc_init);
module_exit(abc_fini);
The problem with my code is that when i compile my kernel module with make, sys/wait.h gives compiling errors like "redefinition of some strcut xyz" any many more errors, when linux/module.h and linux/kthread.h are also included. As soon as i comment out these two files, the module compiles well but gives a linking error that "waitpid" is undefined.
Why doesnt sys/wait.h compile well with linux/kthread.h and linux/module.h? Has anyone encountered this problem before?
Any help would be appreciated.
It is incorrect to include userspace headers, like sys/wait.h, in kernel code.

OpenMP in Visual Studio 2005

I am attempting to use OpenMP to create a parallel for loop in Visual Studio 2005 Professional. I have included omp.h and specified the /openmp compiler flag. However, I cannot get even the simplest parallel for loop to compile.
#pragma omp parallel for
for ( int i = 0; i < 10; ++i )
{
int a = i + i;
}
The above produces Compiler Error C3005 at the #pragma line.
Google hasn't been much help. I only found one obscure Japanese website with a user having similar issues. No mention of a resolution.
A standard parallel block compiles fine.
#prgram omp parallel
{
// Do some stuff
}
That is until you try to add a for loop.
#pragma omp parallel
{
#pragma omp for
for ( int i = 0; i < 10; ++i )
{
int a = i + i;
}
}
The above causes Compiler Error C3001. It seems 'for' is confusing to the compiler, but it shouldn't be. Any ideas?
I found the problem. Some genius defined the following macro deep within the headers:
#define for if ( false ) ; else for
My only guess is this was used to get variables declared in for loops to scope properly in Visual C++ 6. Undefining or commenting out the macro resolved the issue.

Resources