Unix*

uOS Build

Hello!

During OS programming for the PHI, the need exists to permanently install RPM's.

Is there a systematic solution for determining and generating changes required to the uOS on a per RPM basis?

Seems like the process would involve an initial analysis of the RPM for contents.

Then the appropriate modifications to the PHI filelist need implemented.

Any thoughts on additional requirements?

 

 

One option that I've overlooked is to use an NFS share as the root for the PHI.

The DRNG Library and Manual

An introduction to the DRNG Library. Includes download links for the static binary libraries, source code, and documentation and a guide to getting started.
  • Desarrolladores
  • Socios
  • Apple OS X*
  • Linux*
  • Microsoft Windows* (XP, Vista, 7)
  • Microsoft Windows* 8.x
  • Unix*
  • Cliente empresarial
  • Servidor
  • C/C++
  • DRNG
  • rdrand
  • rdseed
  • intel data protection with secure key
  • Secure Key
  • Seguridad
  • Performance issues with Intel MPI (RMA Put/Get) on Xeon Phi

    I'm getting bad performance with MPI_Put (and MPI_Get) in IMB-RMA All_put_all microbenchmark on this system configuration:

    • Single and multiple Xeon Phi coprocessors
    • Intel MPSS 3.5.1 (June 2015), Linux
    • Intel MPI Library 5.1.0.079
    • OFED-3.12-1 or OFED-3.18-rc3 (It doesn't really matter.)

    Intel MPI runtime environment variables:

    offload error: cannot release buffer memory on device 0 (error code 14)

    I need your help. 

    I tried to run K-means algorithm on Xeon Phi by using offload mode.

    But when i tried to get into offload region with the clause '#pragma offload ~~ (as attached pic 1) ' ,

    i got an erorr 'offload error: cannot release buffer memory on device 0 (error code 14)' .

    I have no idea to solve this problem, and i even cannot find any previous example similar to my problem on google.

    I saw offload report by using 'export OFFLOAD_REPORT=3', but i couldn't get any hints. 

    plz help me !

    regards

    TaeHyeok, Jang

    How to protect code from triggering MIC build on non-MIC nodes

    Hello,
    we have two clusters in-house, one with MIC cards and another without. When we build code with OpenMP 4.x pragmas or functions for devices, we get a compilation error on the cluster without MIC cards:

    icc: warning #10362: Environment configuration problem encountered.
    Please check for proper MPSS installation and environment setup.
    testomp.c(1): catastrophic error: *MIC* cannot open source file "stdio.h"
       #include <stdio.h> 

     

    micnativeloadex problem

    Hello,

    I am trying to run a program natively using micnativeloadex but ran into a few problems.

    a) I set: export SINK_LD_LIBRARY_PATH=/opt/intel/composer_xe_2015.3.187/compiler/lib/mic/

    b) I compiled with: "icpc -mmic -qopenmp -o test_native test_native.cc"

    c) micnativeloadex test_native

    It seems the SINK_LD_LIBRARY_PATH isn't been set. The result I get is:

    Fortran OpenMP on Intel Xeon Phi

     

    My questions are very simple. We have intel visual fortran 2015 and fortran subroutines parallelized with OpenMP directives. Is the compiled code be capable of using all the available threads on the Intel Xeon Phi? Would it be required to modify the code to make it compliant with these new processors?

    Our intention is to use already-parallelized code on Intel Xeon Phi or a similar MIC processor. Any suggestions or links on how to do this?

    Thanks,

    Suscribirse a Unix*