Inconsistencies with declaration of 64-bit integers ( signed and unsigned ) in many MKL functions

[SergeyKostrov]

There are inconsistencies with declaration of 64-bit integers ( signed and unsigned ) in many MKL functions. In mkl_types.h there is a declaration:

/* MKL integer types for LP64 and ILP64 */
#if (!defined(__INTEL_COMPILER)) & defined(_MSC_VER)
    #define MKL_INT64 __int64
    #define MKL_UINT64 unsigned __int64
#else
    #define MKL_INT64 long long int
    #define MKL_UINT64 unsigned long long int
#endif

So, MKL_INT64 type is a portable declaration. However, in many MKL functions non-portable declarations long long int and unsigned long long int are used. It creates lots of problems if some legacy C++ compilers are used. For example, Borland C++ v5.x doesn't support  long long int and unsigned long long int types.

[mecej4]

It is futile to attempt using 64-bit MKL libraries using a 32-bit C compiler. Apart from the 64-bit signed integer problems that you brought up, pointer size, instruction set and ABI are mismatched, and the RTL is unsuitable.

[SergeyKostrov]

>>...and the RTL is unsuitable... I'm talking about 64-bit data types and Not 64-bit MKL libraries and everything I needed works (!) already in a 32-bit test environment. >>...It is futile to attempt using 64-bit MKL libraries using a 32-bit C compiler... No, I don't use 64-bit MKL DLLs with a 32-bit application built with a 32-bit Borland C++ compiler . Once again, 32-bit Borland C++ compiler supports __in64 data type ( built-in ) and doesn't support declarations long long int or unsigned long long int. Also, I've succesfully created a software development environment ( a project for a 32-bit Windows platform / a 32-bit Windows application ) that uses 32-bit MKL with Borland C++ compiler but I was forced to modify some MKL headers because of these inconsistencies with declarations. So, as soon as another developer, who will maintain the codes, will do update for MKL all modified headers will be overwritten and compilation will be broken. Take into account that in some labs at some universities free legacy C++ compilers are still used.

[SergeyKostrov]

>>...It is futile to attempt... I greatly appreciate a really professional / technical feedback and I don't think we need to discuss if this is futile attempt or who needs this, etc.

[mecej4]

Sergey,

The first line of the code snippet that you included from mkl.h contained " MKL integer types for LP64 and ILP64 ", and I (incorrectly, it now appears) took it for granted that you were using the LP64 or ILP64 libraries. For the same reason, I did not bother to check whether these lines in mkl.h might remain after preprocessing in 32-bit mode.

[Zhang_Z_Intel]

MKL does not support Borland C++ compiler. This is the full list of C/C++ compilers supported on Windows. See more information about MKL system requirments here: http://software.intel.com/en-us/articles/intel-mkl-110-system-requirements/

Supported C/C++ and Fortran compilers for Windows*:

• Intel® Visual Fortran Composer XE 2013 for Windows* OS
• Intel® Visual Fortran Compiler 13.0 for Windows* OS
• Intel® Visual Fortran Compiler 13.1 for Windows* OS
• Intel® C++ Composer XE 2013 for Windows* OS
• Intel® C++ Compiler 13.0 for Windows* OS
• Intel® C++ Compiler 13.1 for Windows* OS
• Microsoft Visual Studio* 2011 - help file and environment integration
• Microsoft Visual Studio* 2010 - help file and environment integration
• Microsoft Visual Studio* 2008 - help file and environment integration
• Microsoft Visual Studio* 2005 Team Suite Edition - help file and environment integration
• Microsoft Windows* SDK for Windows* 7 (Intel® 64)
• Microsoft Windows* Software Development Kit Update for Windows Vista* (Intel® 64)
• Microsoft Windows Server* 2003 R2 Platform SDK (Intel® 64)
• Microsoft Windows* Software Development Kit for Windows Server* 2008
• PGI* Workstation Complete version 12.5

[SergeyKostrov]

Zhang, A note could be added that any 32-bit versions of MKL could be used with legacy 32-bit Borland C++ compiler(s) and with latest versions of 32-bit MinGW C++ compiler(s). However, some modifications in header files are needed. What I see that there is still some misunderstanding what I'm talking about and because of this I will provide additional technical details. I detected lots of issues with declarations of MKL functions and they need to be addressed in order to improve portability of MKL. So, my report is almost ready and I will post it soon. In overall, it took just two working days to integrate MKL and Borland C++ compiler. Thank you everybody for feedbacks!

[SergeyKostrov]

[ Note 1 ] All cases when declarations long long int or unsigned long long int are used need to be replaced with portable, like: ... #define MKL_INT64 __int64 #define MKL_UINT64 unsigned __int64 ... [ Note 2 ] mkl_lapacke.h is Not included in mkl_types.h [ Note 3 ] Even if in mkl.h there is a define MKL_CALL_CONV: ... #if defined( MKL_STDCALL ) #define MKL_CALL_CONV __stdcall #else #define MKL_CALL_CONV __cdecl #endif ... some MKL functions, like cblas_sgemm, are Not declared with any specificator. For example, see in mkl_cblas.h header file: ... void cblas_sgemm(const CBLAS_ORDER Order, const CBLAS_TRANSPOSE TransA, const CBLAS_TRANSPOSE TransB, const MKL_INT M, const MKL_INT N, const MKL_INT K, const float alpha, const float *A, const MKL_INT lda, const float *B, const MKL_INT ldb, const float beta, float *C, const MKL_INT ldc); ...

[SergeyKostrov]

[ Note 4 ] It would be nice to have a set of macros that control inclusion of all MKL headers files in mkl.h. So, instead of ... #include "mkl_blas.h" #include "mkl_dfti.h" #include "mkl_cblas.h" #include "mkl_lapack.h" #include "mkl_solver.h" #include "mkl_vml.h" #include "mkl_vsl.h" #include "mkl_df.h" #include "mkl_service.h" ... to have something like ( more controllable way): ... #ifndef _NO_MKL_BLAS_ #include "mkl_blas.h" #endif #ifndef _NO_MKL_DFTI_ #include "mkl_dfti.h" #endif #ifndef _NO_MKL_CBLAS_ #include "mkl_cblas.h" #endif #ifndef _NO_MKL_LAPACK_ #include "mkl_lapack.h" #endif #ifndef _NO_MKL_SOLVER_ #include "mkl_solver.h" #endif #ifndef _NO_MKL_VML_ #include "mkl_vml.h" #endif #ifndef _NO_MKL_VSL_ #include "mkl_vsl.h" #endif #ifndef _NO_MKL_DT_ #include "mkl_df.h" #endif #ifndef _NO_MKL_SERVICE_ #include "mkl_service.h" #endif ... and it means if a developer doesn't need any functions from mkl_service.h header file it could be controlled as follows: #define _NO_MKL_SERVICE_ #include "mkl.h" and so on.

[SergeyKostrov]

Correction for [ Note 2 ] mkl_lapacke.h is Not included in mkl.h

[SergeyKostrov]

My updates affected these MKL header files: mkl_types.h mkl_cblas.h mkl_pardiso.h mkl_vsl_functions.h and five Borland linker compatible import libraries created: mkl_rt.lib mkl_core.lib mkl_def.lib mkl_sequential.lib mkl_scalapack_core.lib

[SergeyKostrov]

Here are results of a simple matrix multiplication test with four MKL functions: Application - BccTestApp - WIN32_BCC - Debug Tests: Start > Test1153 Start < Sub-Test 1.1 Intel(R) Math Kernel Library Version 10.3.12 Product Build 20120831 for 32-bit applications Major version : 10 Minor version : 3 Update version : 12 Sub-Test 1.2 - Runtime binding of MKL functions Completed Sub-Test 3.2 - SGEMM Matrix multiplication C[ 1024x1024 ] = A[ 1024x1024 ] * B[ 1024x1024 ] Allocating memory for matrices ( 32-byte alignment ) Intializing matrix data Measuring performance of SGEMM function Iteration 01 - Completed in 0.531 secs Iteration 02 - Completed in 0.500 secs Iteration 03 - Completed in 0.516 secs Iteration 04 - Completed in 0.515 secs Iteration 05 - Completed in 0.516 secs Deallocating memory Sub-Test 3.3 - CBLAS_SGEMM Matrix multiplication C[ 1024x1024 ] = A[ 1024x1024 ] * B[ 1024x1024 ] Allocating memory for matrices ( 32-byte alignment ) Intializing matrix data Measuring performance of CBLAS_SGEMM function Iteration 01 - Completed in 0.515 secs Iteration 02 - Completed in 0.532 secs Iteration 03 - Completed in 0.515 secs Iteration 04 - Completed in 0.516 secs Iteration 05 - Completed in 0.516 secs Deallocating memory Sub-Test 3.4 - DGEMM Matrix multiplication C[ 1024x1024 ] = A[ 1024x1024 ] * B[ 1024x1024 ] Allocating memory for matrices ( 64-byte alignment ) Intializing matrix data Measuring performance of DGEMM function Iteration 01 - Completed in 0.922 secs Iteration 02 - Completed in 0.922 secs Iteration 03 - Completed in 0.922 secs Iteration 04 - Completed in 0.921 secs Iteration 05 - Completed in 0.922 secs Deallocating memory Sub-Test 3.5 - CBLAS_DGEMM Matrix multiplication C[ 1024x1024 ] = A[ 1024x1024 ] * B[ 1024x1024 ] Allocating memory for matrices ( 64-byte alignment ) Intializing matrix data Measuring performance of CBLAS_DGEMM function Iteration 01 - Completed in 0.922 secs Iteration 02 - Completed in 0.969 secs Iteration 03 - Completed in 0.906 secs Iteration 04 - Completed in 0.938 secs Iteration 05 - Completed in 0.890 secs Deallocating memory > Test1153 End < Tests: Completed Memory Blocks Allocated : 12 Memory Blocks Released : 12 Memory Blocks NOT Released: 0 Memory Tracer Integrity Verified - Memory Leaks NOT Detected Deallocating Memory Tracer Data Table Completed

[SergeyKostrov]

Tests results with different C++ compilers for SGEMM function are very consistent because the same MKL runtime DLLs are used: [ Intel C++ compiler ] ... Measuring performance of SGEMM function Iteration 01 - Completed in 0.532 secs Iteration 02 - Completed in 0.515 secs Iteration 03 - Completed in 0.516 secs Iteration 04 - Completed in 0.516 secs Iteration 05 - Completed in 0.500 secs ... [ Borland C++ compiler ] ... Measuring performance of SGEMM function Iteration 01 - Completed in 0.516 secs Iteration 02 - Completed in 0.516 secs Iteration 03 - Completed in 0.515 secs Iteration 04 - Completed in 0.516 secs Iteration 05 - Completed in 0.515 secs ... [ Microsoft C++ compiler ] ... Measuring performance of SGEMM function Iteration 01 - Completed in 0.515 secs Iteration 02 - Completed in 0.532 secs Iteration 03 - Completed in 0.531 secs Iteration 04 - Completed in 0.531 secs Iteration 05 - Completed in 0.500 secs ...

[SergeyKostrov]

[ Correction for Note 1 ] All cases when declarations long long int or unsigned long long int are used need to be replaced with portable MKL_INT64 or MKL_UINT64 based on: ... #define MKL_INT64 __int64 #define MKL_UINT64 unsigned __int64 ...

[mecej4]

I am just a casual user of C, but it seems to me that replacing long long int with __int64 would reduce portability. The C99 standard (see for example http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf, section 6.2.5.4) specifies long long int to be a standard integer type. There is no mention of __int64 in the document, and GCC does not recognize it as a native type; perhaps it is a Microsoft C extension that is also supported by Borland C.

[Zhang_Z_Intel]

Sergey,

Thank you very much for your extensive notes. We will take this into consideration as part of our ongoing effort of making MKL more portable. If you know more about how widely Borland C++ compiler and other legacy compilers are still used in some organizations, please let us know your insight. This will help us to justify our effort.

Thanks again.

[TimP]

http://msinttypes.googlecode.com/svn/trunk/stdint.h

is a visual studio compatible implementation of stdint.h.  I see advantages in such additions to promote portable use of data types.

[SergeyKostrov]

Thanks for the note about C99 standard. >>...GCC does not recognize it as a native type; perhaps it is a Microsoft C extension that is also supported >>by Borland C... I think initially it could be a joint effort by Intel ( 64-bit instructions set in a CPU \ C++ compiler ) and Microsoft ( support of 64-bit instructions set in OSs \ C++ compiler ). Since Borland was always claiming that compatibility of Borland C++ compiler with Microsoft C++ compiler is very-very high it didn't have a choice and of course it supported these 64-bit types. Ideally these portable declarations should look like ( in pseudo-codes / more choices as you can see ): #if ( MSC & ICC ) #define MKL_INT64 __int64 #define MKL_UINT64 unsigned __int64 #endif #if ( SOME_LEGACY_COMPILER ) #define MKL_INT64 long long int #define MKL_UINT64 unsigned long long int #endif #if ( C99_STANDARD ) #define MKL_INT64 long long int #define MKL_UINT64 unsigned long long int #endif #if ( GCC ) #define MKL_INT64 long long int #define MKL_UINT64 unsigned long long int #endif #if ( BCC & MINGW ) #define MKL_INT64 __int64 #define MKL_UINT64 unsigned __int64 #endif #if ( MKL_INT64 & MKL_UINT64 Not defined ) #pragma error ( "MKL_INT64 & MKL_UINT64 are Not defined" ) #endif and the most important: [ Allowed declaration of MKL function ] void _CALLING_CONV_ SomeMklFunction( MKL_INT64 arg1, MKL_UINT64 arg2 ); [ Not Allowed declaration of MKL function ] void _CALLING_CONV_ SomeMklFunction( long long int arg1, unsigned long long int arg2 );

[SergeyKostrov]

>>...If you know more about how widely Borland C++ compiler and other legacy compilers are still used in some organizations, >>please let us know your insight... Unfortunately, I don't have any statistics about usage of legacy C++ compilers. However, take into account that lots of applications were compiled / built with Borland C++ compiler in the past and they still could be used in universities, in small software companies, by independent software developers, etc. >>...This will help us to justify our effort... It makes sense to consider and if a positive decision will be made all updates need to be done step by step ( one MKL domain at a time ) because MKL is a very big library.

[SergeyKostrov]

Thanks, Tim. >>...is a visual studio compatible implementation of stdint.h. I see advantages in such additions to promote portable >>use of data types... I see now where the root cause of the problem is and technical details will be provided after I'll look at some headers from all C++ compilers I use.

[barragan_villanueva_]

Hi,

As I understand the main problem here is in customization of MKL types. Please look at corresponding KB article  http://software.intel.com/en-us/articles/use-of-intel-mkl-data-types-in-cc-applications. Maybe, MKL_UINT64 should allow such customization too as it is done for MKL_INT. However, MKL is common library for C/C++ and FORTRAN. But FORTRAN has no unsigned interger types. Therefore, MKL_UINT and MKL_UINT64 types are kind of C-related compromises in MKL interfaces which look like unnecessary.