- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried building in VS2005 a solution with two IVF projects: one an exe, and the other a dll. This is an x64 app built on an x64 host (Windows).
I use some BLAS MKL routines, one of which is "dot". I INCLUDE in a MODULE the MKL-provided source file "mkl_blas_protos.f90" found on my machine in "C:Program FilesIntelMKL9.1interfaceslas95source". That MKL-provided source file houses a single MODULE called "MKL77_BLAS", within which there is an INTERFACE called "MKL77_DOT", which provides two interfaces: one for "SDOT", and one for "DDOT" (therefore making a generic called "MKL77_DOT"). In a subsequent module (in the same source file) I include "sdot.f90" and "ddot.f90" from the same above-mentioned MKL-provided source directory. "sdot.f90" houses a PURE FUNCTION called "SDOT_MKL95", and "ddot.f90" houses a PURE FUNCTION called "DDOT_MKL95". In "sdot.f90", for example, there is a USE statement referencing "MKL77_BLAS", with an ONLY: MKL77_DOT on the same use line, and the identical USE statement is found in "ddot.f90" for "DDOT_MKL95" pure function.
Above those INCLUDEs (INCLUDE 'sdot.f90'; INCLUDE 'ddot.f90') in this subsequent MODULE of my source, I define a generic interface called "DOT", and call out "SDOT_MKL95" and "DDOT_MKL95" in that generic interface as MODULE PROCEDUREs.
It's pretty tenuous, but this combines to define a generic "DOT" in my source which disambiguates on the REAL kind type parameter of the rank one REAL arguments to "DOT". Thus are implemented the Fortran-95 wrappers to the MKL-provided BLAS routines for dot product in my source.
Here's my problem: within the MKL Fortran 77 and 95 interfaces, the working precision ("WP") is an INTEGER PARAMETER which "gets" the kind type parameter for the REAL arguments through "WP = KIND(1.0E0)" for SDOT_MKL95 and "WP = KIND(1.0D0)" for DDOT_MKL95, as well as in the interfaces for SDOT and DDOT in the generic interface MKL77_DOT. So, I *assume* the *default* working precision is based on the *default* kind type parameters *at the time of the build*.
In my source I defined two PARAMETERs: DP = KIND(1.0D0) and SP = KIND(1.0E0). Thus I additionally *assume* those parameters are set to the IVF internal representation of the kind type parameters for double and single precision reals, respectively, *at build time*.
Now, when I go into "properties" of the two projects of this solution I set the *default* single and double precisions to "8" and "16", respectively, which is double that if I just let those settings "".
When I do that, I get incorrect results (where exactly that happens I've no idea).
When I set in IVF the default single and double precisions to "4" and "8" respectively, I obtain expected and correct results.
Am I incorrect in assuming the "working precision" within the MKL routines is *set at build time*?
If that is intended behavior (non-dynamic, at build time, setting of default real precisions in MKL), I suggest the MKL documentation address it. If it's not intended behavior, then it's time for a problem report.
Brian Lamm
One thing I might add: when I set the *default* precision of INTEGERs in IVF to "8", I obtain correct results (with default single and double precision reals set in IVF to "4" and "8", respectively).
I use some BLAS MKL routines, one of which is "dot". I INCLUDE in a MODULE the MKL-provided source file "mkl_blas_protos.f90" found on my machine in "C:Program FilesIntelMKL9.1interfaceslas95source". That MKL-provided source file houses a single MODULE called "MKL77_BLAS", within which there is an INTERFACE called "MKL77_DOT", which provides two interfaces: one for "SDOT", and one for "DDOT" (therefore making a generic called "MKL77_DOT"). In a subsequent module (in the same source file) I include "sdot.f90" and "ddot.f90" from the same above-mentioned MKL-provided source directory. "sdot.f90" houses a PURE FUNCTION called "SDOT_MKL95", and "ddot.f90" houses a PURE FUNCTION called "DDOT_MKL95". In "sdot.f90", for example, there is a USE statement referencing "MKL77_BLAS", with an ONLY: MKL77_DOT on the same use line, and the identical USE statement is found in "ddot.f90" for "DDOT_MKL95" pure function.
Above those INCLUDEs (INCLUDE 'sdot.f90'; INCLUDE 'ddot.f90') in this subsequent MODULE of my source, I define a generic interface called "DOT", and call out "SDOT_MKL95" and "DDOT_MKL95" in that generic interface as MODULE PROCEDUREs.
It's pretty tenuous, but this combines to define a generic "DOT" in my source which disambiguates on the REAL kind type parameter of the rank one REAL arguments to "DOT". Thus are implemented the Fortran-95 wrappers to the MKL-provided BLAS routines for dot product in my source.
Here's my problem: within the MKL Fortran 77 and 95 interfaces, the working precision ("WP") is an INTEGER PARAMETER which "gets" the kind type parameter for the REAL arguments through "WP = KIND(1.0E0)" for SDOT_MKL95 and "WP = KIND(1.0D0)" for DDOT_MKL95, as well as in the interfaces for SDOT and DDOT in the generic interface MKL77_DOT. So, I *assume* the *default* working precision is based on the *default* kind type parameters *at the time of the build*.
In my source I defined two PARAMETERs: DP = KIND(1.0D0) and SP = KIND(1.0E0). Thus I additionally *assume* those parameters are set to the IVF internal representation of the kind type parameters for double and single precision reals, respectively, *at build time*.
Now, when I go into "properties" of the two projects of this solution I set the *default* single and double precisions to "8" and "16", respectively, which is double that if I just let those settings "
When I do that, I get incorrect results (where exactly that happens I've no idea).
When I set in IVF the default single and double precisions to "4" and "8" respectively, I obtain expected and correct results.
Am I incorrect in assuming the "working precision" within the MKL routines is *set at build time*?
If that is intended behavior (non-dynamic, at build time, setting of default real precisions in MKL), I suggest the MKL documentation address it. If it's not intended behavior, then it's time for a problem report.
Brian Lamm
One thing I might add: when I set the *default* precision of INTEGERs in IVF to "8", I obtain correct results (with default single and double precision reals set in IVF to "4" and "8", respectively).
Link Copied
3 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
MKL has no support for the 16 byte data types of ifort. Yes, the MKL library data types are compiled in, with the S? functions taking 32-bit reals, and the D? functions taking 64-bit reals. If you have 64-bit integers in your BLAS calls, you must link with the ilp64 libraries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Okay, thanks. Not very impressive, but thanks.
No support for 64-bit integers (unless one links with ilp64)? I wonder why I didn't get any result errors. Perhaps my test arrays were not large enough.
At least now I understand the problem.
Seems like a needless roadblock, however. Why not compile "double" versions (64-bit single and 128-bit double precision) and make them available?
Will MKL one day support 64-bit for S? and 128-bit for D? ?
Brian Lamm
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We have resisted supplying 128-bit arithmetic because 1) performance and 2) naming space (qgemm for 128-bit real gemm?).
We will have, with MKL 10.0 beta, a mapping from the single precision BLAS functions to 64-bit functions in response to requests from some FEA code vendors who have code created for the Cray architecture.
Bruce
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page