Intel® oneAPI Math Kernel Library
Ask questions and share information with other developers who use Intel® Math Kernel Library.

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

SergeyKostrov
Valued Contributor II
1,624 Views

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.

 

0 Kudos
35 Replies
barragan_villanueva_
Valued Contributor I
439 Views

Sergey,

My previous post was for your Note1. In my opinion, it’s better to allow/use customization of MKL types instead of collection of all type variants for currently available compilers.

See my comments below on other your Notes2-4.

2) As to mkl_lapacke.h. It is interface for LAPACKE component and it is already part of mkl.h header.

3) As to CDECL/STDCALL calling convention for MKL functions. You know not all functions in MKL can have types of calling conventions. For example some DFTI functions are defined with ellipsis which is not allowed for STDCALL. Maybe some corrections are required to fix MKL interfaces if they need CDECL/STDCALL. We need to check it for CBLAS you mentioned.

4) As to control inclusion of all MKL headers files in mkl.h. I don’t like your suggestion introducing additional macros for including MKL components. In my opinion mkl.h is common MKL header file which includes all MKL components. But if some application needs just several of them it’s better to list them directly instead of mkl.h.

For example to use LAPACKE and SERVICE components:

#include “mkl_types.h”

#include “mkl_lapacke.h”

#include “mkl_service.h”

 

0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
>>...As I understand the main problem here is in customization of MKL types... No. Declarations of MKL functions should Not use any unwrapped types and see my previous posts.
0 Kudos
SergeyKostrov
Valued Contributor II
438 Views
Here is example: Currently declared ... /* SkipAheadStream - skip-ahead method */ #if defined( _MSC_VER ) _Mkl_Api(int,vslSkipAheadStream,(VSLStreamStatePtr , const __int64 )) _mkl_api(int,vslskipaheadstream,(VSLStreamStatePtr *, const __int64 *)) _MKL_API(int,VSLSKIPAHEADSTREAM,(VSLStreamStatePtr *, const __int64 *)) #else _Mkl_Api(int,vslSkipAheadStream,(VSLStreamStatePtr , const long long int )) _mkl_api(int,vslskipaheadstream,(VSLStreamStatePtr *, const long long int *)) _MKL_API(int,VSLSKIPAHEADSTREAM,(VSLStreamStatePtr *, const long long int *)) #endif ... A modified version 1 ... /* SkipAheadStream - skip-ahead method */ #if defined( _MSC_VER ) _Mkl_Api(int,vslSkipAheadStream,(VSLStreamStatePtr , const __int64 )) _mkl_api(int,vslskipaheadstream,(VSLStreamStatePtr *, const __int64 *)) _MKL_API(int,VSLSKIPAHEADSTREAM,(VSLStreamStatePtr *, const __int64 *)) #else _Mkl_Api(int,vslSkipAheadStream,(VSLStreamStatePtr , const MKL_INT64 )) _mkl_api(int,vslskipaheadstream,(VSLStreamStatePtr *, const MKL_INT64 *)) _MKL_API(int,VSLSKIPAHEADSTREAM,(VSLStreamStatePtr *, const MKL_INT64 *)) #endif ... Or A modified version 2 ... /* SkipAheadStream - skip-ahead method */ _Mkl_Api(int,vslSkipAheadStream,(VSLStreamStatePtr , const MKL_INT64 )) _mkl_api(int,vslskipaheadstream,(VSLStreamStatePtr *, const MKL_INT64 *)) _MKL_API(int,VSLSKIPAHEADSTREAM,(VSLStreamStatePtr *, const MKL_INT64 *)) ... Note: Both versions of modifications Don't change internals of these MKL functions and could be applied very easily ( this is what I was forced to do ).
0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
>>...I don’t like your suggestion introducing additional macros for including MKL components. In my opinion... I don't think a final decision should be based just on your or my opinions. I regret to see that in some cases developers are trying to "...make an elefant from a fly..." and ready to discuss some subject for weeks if not months when very simple solutions exist.
0 Kudos
barragan_villanueva_
Valued Contributor I
439 Views

Sergey,

Firstly, you suggested to change MKL_UINT64 definition to comply with Borland C++. So I said that it's your main problem which can be resolved via customization of MKL_UINT64 type.

As to your comments related to SkipAheadStream definitions, you are right they should use MKL_INT64 type.

0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
Did you read my previous post? I gave a clear example of some problem with declaration of several MKL functions: Currently declared ... /* SkipAheadStream - skip-ahead method */ #if defined ( _MSC_VER ) _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const __int64 ) ) _mkl_api( int, vslskipaheadstream, (VSLStreamStatePtr *, const __int64 * ) ) _MKL_API( int, VSLSKIPAHEADSTREAM, (VSLStreamStatePtr *, const __int64 * ) ) #else _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const long long int ) ) _mkl_api( int, vslskipaheadstream, (VSLStreamStatePtr *, const long long int * ) ) _MKL_API( int, VSLSKIPAHEADSTREAM, (VSLStreamStatePtr *, const long long int * ) ) #endif ... Once again, these are codes implemented by Intel software developer and they have Non Portable data types long long int and __int64. Consider it as a bug that could be fixed in less than one minute. Sorry, but we spent more time on writing and reading posts in that thread.
0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
>>...So I said that it's your main problem which can be resolved via customization of MKL_UINT64 type. Yes, I can do customization and this is actually what I've done by modifying several MKL header files. Now, the main concern / problem is that as soon as another developer ( it is out of my control ) will update MKL all these modifications will be gone. Of course, I could make some instructions but, you know, they could be ignored, or forgotten, etc. Looking ahead I see that as soon as a new update of MKL is installed compilation of sources will be broken if my instructions are not followed by. Also, I've just completed a verification with MinGW C++ compiler and it perfectly works with long long int-like data types and in overall it took me less than 2 hours to integrate MKL and MinGW. My conclusion is that MKL could be used with legacy C++ compilers, like Borland ( 32-bit only ), and with GCC-like C++ compiler for Windows, like MinGW ( 32-bit & 64-bit ), but some modifications currently needed in MKL header files. A good thing is that these modifications are very small and don't affect internal implementations of any MKL functions. So, if my suggestions will be applied some time in the future it will be awesome. Thank you in advance.
0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
Just for consistency with currently used #ifdefs in another header files: Instead of ... /* SkipAheadStream - skip-ahead method */ #if defined ( _MSC_VER ) _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const __int64 ) ) ... #else _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const long long int ) ) ... #endif ... I think a verification for __INTEL_COMPILER is needed ... /* SkipAheadStream - skip-ahead method */ #if ( !defined( __INTEL_COMPILER ) ) & defined( _MSC_VER ) _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const __int64 ) ) ... #else _Mkl_Api( int, vslSkipAheadStream, (VSLStreamStatePtr , const long long int ) ) ... #endif ...
0 Kudos
Bernard
Black Belt
439 Views

>>>perhaps it is a Microsoft C extension that is also supported by Borland C.>>>

__int64 is Microsoft type specifier.

0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
>>>>...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. I still didn't have time to look at it and I hope that I'll do it tomorrow.
0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
Additional verification shows that these four legacy C/C++ compilers do not support declarations long long int and unsigned long long int: Borland C++ v5.x Visual C++ 6.x ( also known as Visual Studio 98 ) Turbo C++ v3.x Turbo C++ v1.x Even if all tested C/C++ compilers ( released after 2000 ) support these declarations I don't see any reason to support them in MKL because __int64 and unsigned __int64 built-in types exist. By the way, Intel's intrinsic headers do not have these declarations at all and all 64-bit types are based on __int64 and unsigned __int64 built-in types.
0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
#include "stdio.h" typedef long int LINT; typedef long long int LLINT; LINT liValue = 0; LLINT lliValue = 0; int main( void ) { printf( "sizeof( LINT ) = %d\n", sizeof( LINT ) ); printf( "sizeof( LLINT ) = %d\n", sizeof( LLINT ) ); return ( int )0; }
0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
Zhang, Victor, This is simply to let you know that the same modifications with MKL header files are needed in case of using MKL version 11.0.2 with Borland C++ compiler version 5.x. A good thing is MKL functions also perfectly work.
0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
This is a message for David regarding integration of MKL with Borland C++ compilers: David, Please do not send me messages using IDZ Messaging System since I'm no longer using it. Sorry about it.
0 Kudos
SergeyKostrov
Valued Contributor II
439 Views
>>This is a message for David regarding integration of MKL with Borland C++ compilers: >> >>David, >> >>Please do not send me messages using IDZ Messaging System since I'm no longer using it. Sorry about it. David, Could you provide some update on a status of your work related to integration of MKL with a version 10 of Borland C++ compiler? Could you also provide more details about the compiler? Thanks.
0 Kudos
Reply