Limitations to the sparse solver and optimization solvers in Intel® MKL 10.0 Update 2:

• Sparse and optimization solver libraries functions are only provided in static form

Limitations to the FFT functions in Intel MKL 10.0 Update 2:

• The function DftiCopyDescriptor is not implemented
• Mode DFTI_TRANSPOSE is implemented only for the default case
• Mode DFTI_REAL_STORAGE can have the default value only and is not changeable 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 ³¹-1. Any 1D FFT larger than 2 ³¹-1 or any multi-dimensional FFT with any dimension greater than 2 ³¹-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 ³¹-1 elements; as long as any one dimension length does not exceed 2 ³¹-1

Limitations to the LAPACK functions in Intel MKL 10.0 Update 2:

• 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 dsecond() functions may not provide correct answers in the case where the CPU frequency is not constant.

Limitations to the interval arithmetic functions in Intel MKL 10.0 Update 2:

• The interval libraries will require the libifcore library from Intel® Fortran compiler.
• Interval arithmetic functions require a processor which supports SSE instructions.

Limitations to static Intel® MKL libraries for systems with Intel® EM64T:

• To bind with static Intel® MKL libraries for EM64T, you need Xcode* version 2.4.1 as the linker which comes with older Xcode* versions fails to bind. This limitation doesn't affect dynamic libraries for Intel® EM64T or libraries (dynamic or static) for IA-32.

FFT, VML, VSL, 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 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' in includemkl.fi 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 an 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.

Other: GMP and Interval Solver components are located in the solver library. For Intel® 64 platform these components support only LP64 interface.

Operating System:

Limitations to the sparse solver and optimization solvers in Intel® MKL 10.0 Update 2:

• Sparse and optimization solver libraries functions are only provided in static form

Limitations to the FFT functions in Intel® MKL 10.0 Update 2:

• The function DftiCopyDescriptor is not implemented
• Mode DFTI_TRANSPOSE is implemented only for the default case
• Mode DFTI_REAL_STORAGE can have the default value only and is not changeable 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 ³¹-1. Any 1D FFT larger than 2 ³¹-1 or any multi-dimensional FFT with any dimension greater than 2 ³¹-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 ³¹-1 elements; as long as any one dimension length does not exceed 2 ³¹-1
• Some limitations exist on arrays sizes for Cluster FFT functions. See mklman.pdf for a detailed description
• When a dynamically linked application uses Cluster FFT functionality, it is required to put the static Intel® MKL interface libraries on the link line as well. 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 -lguide -lpthread

Limitations to the LAPACK functions in Intel® MKL 10.0 Update 2:

• 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 dsecond() functions may not provide correct answers in the case where the CPU frequency is not constant.

Limitations to the Vector Math Library (VML) and Vector Statistical Library (VSL) functions in Intel® MKL 10.0 Update 2:

• Usage of mkl_vml.fi may produce warning about TYPE ERROR_STRUCTURE length

Limitations to the interval arithmetic functions in Intel® MKL 10.0 Update 2:

• The interval libraries will require the libifcore library from Intel® Fortran compiler.
• Interval arithmetic functions require a processor which supports SSE instructions.

Limitations to the ScaLAPACK functions in Intel® MKL 10.0 Update 2:

• 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.
• ScaLAPACK libraries are available only in static form

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.

Limitations to the Java examples:

• The Java examples don’t work with static Intel® MKL libraries. Please use the dynamic Intel® MKL libraries for running the Java examples

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.  For example: g77 -fno-second-underscore test.f

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, VML, VSL, 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 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' in includemkl.fi with the line include 'mkl_vsl_subroutine.fi'. VSL API changes don't affect C/C++ users.

Hyper-Threading Technology (HT Technology) is especially effective when each thread is performing different types of operations and when there are under-utilized resources on the processor. Intel® MKL fits neither of these criteria as the threaded portions of the library execute at high efficiencies (using most of the available resources) and perform identical operations on each thread. You may obtain higher performance when using Intel® MKL without HT Technology enabled.

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 an 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'

Other: GMP and Interval Solver components are located in the solver library. For Intel® 64 and IA-64 platforms these components support only LP64 interface.

Operating System: