Does MKL support real*16 datatype?

[Nan_Deng]

I am trying to convert some old Cray routines with double precision to the Windows Visual Fortran platform, but somehow am having difficulties in making the routines work. Just wondering if MKL have any real*16 routines?

[TimP]

Last time we discussed this topic, it was said there were no such functions in MKL.  The possibility of realizing the performance potential by compiling the open source (e.g. netlib) still stands; there is little scope for expert hand optimization.

[Nan_Deng]

Actually my old Cray routines are Linpack solvers patched to work with real*16.  The routines are compiled without problem in Visual Fortran. However, when I tried to run the program, it gave me "runtime error 157 - Access violation" and pointed to where a real*16 array in the subroutine interface. I wonder if there is any way to get around the problem?

[mecej4]

Note that IEEE 64-bit reals have a 53+1 bit mantissa, which is 4 bits more than Cray single-precision. Are you sure that you need quad precision, and are you willing to live with substantially reduced performance in return?

As far as I know, MKL does not have support for BLAS/Lapack calls with REAL*16 or COMPLEX*32 variables as arguments. However, Intel Fortran does support arithmetic with quad precision, which is performed in software.

I think that you need to be a bit more specific regarding those Cray routines that you are trying to port, and make strong effort to see if you can get by with native floating point arithmetic. For instance, if you want to solve simultaneous linear equations, you could obtain a first solution using Lapack or Pardiso routines in MKL with REAL*8 precision, and then do iterative refinement with REAL*16 precision using your own code.

[mecej4]

Nan Deng wrote:
However, when I tried to run the program, it gave me "runtime error 157 - Access violation" and pointed to where a real*16 array in the subroutine interface. I wonder if there is any way to get around the problem?

Access violations are usually caused by bugs in the source code, such as array overruns, undefined variables, etc. If access violation exceptions were to be ignored, your buggy program would produce junk results, without your even being aware of that. That is not what you really want, is it?

[Nan_Deng]

Mecej4:

Thanks for your suggestions. The original code runs on Cray with double precision. The code is to solve a quadratic eigenvalue problem. On Cray it can give me a precision for eigenvalues of about 30-31 significant digits, the results are correct and repeatable.  Using real*8 and complex*16 with quad iterative improvement on Visual Fortran, I can get at most 18-20 significant digits. So it is unfortunately inadequate.

As for "access violation",  as I said, the code runs perfectly on Cray with no problem at all. When I ported it to Visual Fortran, all I did was to change "double precision" to "real*16" for all relevant variables and I got the runtime error "access violation", and the tracing back point to the subroutine interface especially with array variables.  I wonder if you can offer any specific insight to help me find what and where the "bug" is or any specific test tip to locate the causing lines.

[mecej4]

Nan Deng wrote:
As for "access violation",  as I said, the code runs perfectly on Cray with no problem at all. When I ported it to Visual Fortran, all I did was to change "double precision" to "real*16" for all relevant variables and I got the runtime error "access violation", and the tracing back point to the subroutine interface especially with array variables.  I wonder if you can offer any specific insight to help me find what and where the "bug" is or any specific test tip to locate the causing lines.

Let us put the Cray code aside. You have the modified (ported) code on an X86/X64 computer and that code is crashing. I repeated your porting exercise, but on a smaller scale: I downloaded (from www.netlib.org) the Linpack and Blas source files for solving linear equations, namely, files dgesl.f, dgefa.f, daxpy.f, dscal.f, xdgefa.f, ddot.f and idamax.f, and wrote a small driver to call these routines. I converted all these sources to quad-precision, and obtained correct results. There were no access violations.

It is rather futile to seek specific tips on bugs in unseen code. I think you have to show the code that is causing access violations. Better still, create (if you do not already have it) a double precision version of your code and see if it runs without errors, albeit with less precise results than you aim for. 

[Nan_Deng]

Your point is well taken.  Actually, I used all "c-" routines from Linpack and BLAS and created my Cray version using double precision real since Cray didn't have "z-" type double precision complex at that time. I'll try to download the z-routines from Linpack and BLAS again and use the complex*32 in Visual Fortran, hopefully to get meaningful results.

[Gennady_F_Intel]

Tim Prince wrote:

Last time we discussed this topic, it was said there were no such functions in MKL.  The possibility of realizing the performance potential by compiling the open source (e.g. netlib) still stands; there is little scope for expert hand optimization.

YES, that's actual still now. MKL doesn't support this datatype and currently we don't have plan to support that in the nearest versions. 

[TimP]

Iterative improvement should work with a combination of REAL64 and REAL128, possibly even faster than a single pass of full REAL128. 

http://www.netlib.org/utk/people/JackDongarra/PAPERS/cell-linpack-2006.pdf

appears to be a reference on that.  Being rusty on the subject, I don't know which references are most useful.