Known Limitations in Intel® MKL 10.2

Submit New Article

Last Modified On :   November 13, 2009 5:33 AM PST
Rate
 


The following are known issues in the Intel® Math Kernel Library (Intel® MKL) version 10.2 and its updates.

Limitations to the BLAS functions
  • In version 10.2 there exist problems with the results from DGEMM, SGEMM, and ZGEMM for very specific input cases and on specific processors. See the knowledgebase article for more information.  The problems are fixed in version 10.2 Update 1.
Limitations to the FFT functions
  • Mode DFTI_TRANSPOSE is implemented only for the default case
  • Mode DFTI_REAL_STORAGE can have the default value only and cannot be set by the DftiSetValue function (i.e. DFTI_REAL_STORAGE = DFTI_REAL_REAL)
  • The ILP64 version of Intel® MKL does not currently support FFTs with any one dimension larger than 2^31-1. Any 1D FFT larger than 2^31-1 or any multi-dimensional FFT with any dimension greater than 2^31-1 will return the "DFTI_1D_LENGTH_EXCEEDS_INT32" error message. Note that this does not exclude the possibility of performing multi-dimensional FFTs with more than 2^31-1 elements; as long as any one dimension length does not exceed 2^31-1
  • Some limitations exist on arrays sizes for Cluster FFT functions (Windows* and Linux* versions only). See the reference manual (mklman.pdf) for a detailed description.
  • When a dynamically linked application uses Cluster FFT functionality in the Linux* version, the static Intel® MKL interface libraries are also required on the link line. For example: -Wl,--start-group $MKL_LIB_PATH/libmkl_intel_lp64.a $MKL_LIB_PATH/libmkl_cdft_core.a -Wl,--end-group $MKL_LIB_PATH/libmkl_blacs_intelmpi20_lp64.a -L$MKL_LIB_PATH -lmkl_intel_thread -lmkl_core -liomp5 -lpthread
  • The negative strides are not been supported by version 10.2 and updates

Limitations to the LAPACK functions:
  • The ILAENV function, which is called from the LAPACK routines to choose problem-dependent parameters for the local environment, can not be replaced by a user's version
  • second() and dsecnd() functions may not provide correct answers in the case where the CPU frequency is not constant.
  • As of version 10.0 the following two issues apply when linking to the dynamic libraries:
    • A user provided XERBLA will not be invoked if LAPACK is called with illegal input parameters. The default XERBLA will be used instead.
    • A user may encounter a segment violation if they call the LP64 interface to LAPACK with illegal parameters. This is because a request may be made to allocate a negative amount of memory.

 

Limitations to the Vector Math Library (VML) and Vector Statistical Library (VSL) functions:
  • Usage of mkl_vml.fi may produce warning about TYPE ERROR_STRUCTURE length
  • To create a Windows* DLL that contains references to Intel® MKL functions, the Intel® MKL DLL Builder Tool should be used. Other DLL build techniques are not supported.

 

Limitations to the ScaLAPACK functions:
  • The user can not substitute PJLAENV for their own version. This function is called by ScaLAPACK routines to choose problem-dependent parameters for the local environment.
  • On Windows*, there are possible problems with getting global environment variables such as MKL_BLACS_MPI by -genvlist by MPICH2. In this case, try to set all necessary environment variables by using the control panel. From the System control panel select the "Advanced" tab and click the "Environment Variables" button.

 

Limitations to the ILP64 version of Intel® MKL:
  • The ILP64 version of Intel® MKL does not contain the complete functionality of the library. For a full listing of what is in the ILP64 version refer to the user's guide in the doc directory.
  • g77 can not be used with the ILP64 libraries.

The DHPL_CALL_CBLAS option is not allowed when building the hybrid version of MP LINPACK.


Limitations to the Fortran 95 interface to LAPACK:
  • If you are compiling the Fortran 95 interface to LAPACK with the GNU gfortran compiler, you must manually remove the "pure" attribute from all subroutines containing a procedure argument: ?GEES, ?GEESX, ?GGES, ?GGESX (where ? can be S, D, C, or Z).

 

Limitations to the g77 compiler support:
  • Some Intel® MKL functions contain underscore in their names (i.e. mkl_dcsrsymv, mkl_cspblas_dcsrsymv) and these functions don't support the g77 default naming convention. -fno-second-underscore compilation flag can be used as workaround for this limitation. E.g.: g77 -fno-second-underscore test.f

 

Limitations with static linking on Intel® MKL for Mac OS* X:
  • To bind with static libraries for the Intel® 64 architecture, you need Xcode* version 2.4.1 as the linkers which come with earlier Xcode* versions fail to bind. This limitation doesn't affect dynamic libraries, nor any IA-32 libraries.
  • The Intel® MKL versions earlier than 10.2 update 2 are built by the Intel® C++ Compiler which has the incompatibility problem with XCode 3.2 linker on Mac OS X 10.6 ( Snow Leopard) and as a result Mac OS*X 10.6 doesn't work with static version of libraies when Xcode 3.2 but works when Xcode 3.1.2. Please refer to the article "Linking error on MacOSX 10.6 with XCode 3.2" located here http://software.intel.com/en-us/articles/linking-error-on-macosx-106-with-xcode-32/
Linking Intel® MKL for Windows*:
  • Using /MT when linking with multi-threaded Intel® MKL is recommended. Use of /MD with Microsoft* Visual C++* .NET causes linking errors.

 

Limitations to the Java examples:
  • The Java examples on the Windows* version won't work if the path to the JDK contains spaces. Please use quotes to set JAVA_HOME in those cases. For example: set JAVA_HOME="C:\Program Files\Java\jdk1.6.0_06"

 

On Intel® processors with Intel® EM64T enabled, user programs compiled with the GNU Fortran compiler (version 3.2.3) will likely get incorrect results from those functions in Intel® MKL that return single precision values, if -fno-f2c GNU Fortran compiler flag isn't used. The GNU Fortran compiler by default expects REAL*4 values in the first 8 bytes of the return register (just as a double precision value would be represented) while the Intel® Fortran compiler expects REAL*4 values in the first 4 bytes of the return register. The behavior of Intel® MKL is compatible with that of the Intel Fortran compiler. GNU Fortran compiler behavior could be changed to be compatible with the Intel Fortran compiler by using the -fno-f2c flag.

FFT and PDE Support functions can not be called from Fortran-77. These components have Fortran-90/95 interface specifics (structures, ..) that can not be used with Fortran-77.

We recommend that -Od on Linux* or /Od on Windows be used for the 10.0 Intel® compilers when compiling test source code available with Intel® MKL. Current build scripts do not specify this option and default behavior for these compilers has changed to provide vectorization.

All VSL functions return an error status, i.e., default VSL API is a function style now rather than a subroutine style used in earlier Intel® MKL versions. This means that Fortran users should call VSL routines as functions. For example:

errstatus = vslrnggaussian(method, stream, n, r, a, sigma)

rather than subroutines:

call vslrnggaussian(method, stream, n, r, a, sigma)

Nevertheless, Intel® MKL provides a subroutine-style interface for backward compatibility. To use subroutine-style interface, manually include mkl_vsl_subroutine.fi file instead of mkl_vsl.fi by changing the line include 'mkl_vsl.fi' mkl.fi (in the include directory) with the line include 'mkl_vsl_subroutine.fi'. VSL API changes don't affect C/C++ users.


Memory Allocation:

In order to achieve better performance, memory allocated by Intel® MKL is not released. This behavior is by design and is a one time occurrence for Intel® MKL routines that require workspace memory buffers. Even so, the user should be aware that some tools may report this as a memory leak. Should the user wish, memory can be released by the user program through use of a function MKL_FreeBuffers()) made available in Intel® MKL or memory can be released after each call by setting the environment variable MKL_DISABLE_FAST_MM (see User's Guide in the doc directory for more details). Using one of these methods to release memory will not necessarily stop programs from reporting memory leaks, and in fact may increase the number of such reports should you make multiple calls to the library thereby requiring new allocations with each call. Memory not released by one of the methods described will be released by the system when the program ends. To avoid this restriction disable memory management as described above.

On Red Hat* Enterprise Linux 3.0, in order to ensure that the correct support libraries are linked, the environment variable LD_ASSUME_KERNEL must be set. For example: 'export LD_ASSUME_KERNEL=2.4.1'

 

 





This article applies to: Intel® Math Kernel Library Knowledge Base