Gemm BLAS routine

[Robert_C_2]

Has anyone found an issue on using a BLAS/LAPACK routine after putting the computer in a power save mode?  I have found that the SGEMM routine does not work after the computer awakens from sleep or hibernation.  I have to re-boot my computer to get it to work again.

I have a Dell desktop running Windows 7 and developing Fortran applications.

[TimP]

.

[TimP]

Does it mean your PATH settings aren't restored? Or, do you have typical Windows problems beyond Intel tools? Over a period of 20 years, I've found no solution to such things other than to extend the time before sleep and hibernation. I still need a 5 hour limit to assure ability to complete a file download, and need Intel's download manager for Windows, even though linux can accomplish what Intel online installations require. Intel download sites don't offer more than 400 kb/s across state lines. I don't expect Intel tools PATH settings to last longer than that. I dimly remember how we used to update AOL overnight on a 20kb/s connection. It took me 4 months to learn the new tricks required to make win8.1 work nearly as reliably as win7 (to which I still must revert for those on-line applications which haven't adapted).

[Ying_H_Intel]

HI RoberC, 

Could you show some details  like about how to reproduce the problem? 

Could I use sgemm example in $MKL install directory?. Build it first, then run a exe in command line,   then hibernation, then run a exe again? 

Best Regards,

Ying

[JohnNichols]

I am having a slightly different problem:

I can get dgemm to work nicely, but if I switch to the gemm version I get errors in finding the include files. 

Any ideas?

John

[TimP]

John Nichols wrote:

I am having a slightly different problem:

I can get dgemm to work nicely, but if I switch to the gemm version I get errors in finding the include files. 

Any ideas?

John 

The locations of the blas95 include and .mod files have varied among MKL versions.  You must search them out and set corresponding -I paths in your compile step, or copy them into the preset MKL include paths.

The .mod files are specific to OS (including separate versions for 32- and 64-bit compilation).

[TimP]

Apparently, ifort 15.0 (now available along with MKL 11.2 on beta test) has relaxed the requirements to get blas95 working.

[Robert_C_2]

I have also found that my problem is case specific.  DGEMM works, but CGEMM and ZGEMM do not.  A newer Fortran compiler/MKL library made SGEMM work, but CGEMM and ZGEMM are still not working in the beta version.

[Ying_H_Intel]

Hi Robert, 

The problem looks the OS and power, environment related.  

I did a quick test with my laptop, window 7 with sgemm.  i can't reproduce the problem. 

1. Open one Intel Fortran Command line windows and build the zgemm.f  example under MKL example folder (copy it to temp folder) with command line: nmake libia32 function=zgemm+

2. run it with a.out < zgemmx.d

3. click Fn + F4  hibernate the machine. 

4. click again, awake the machine. 

5. in the same command line windows, enter command : a.out < zgemmx

It works. 

Could you attach your exe and give a instruction how to reproduce the problem? 

Best Regards,

Ying

[mecej4]

Robert:

I tested (on Windows 8.1 Pro 64, i7-2720QM) all the eight GEMM Fortran examples provided with Parallel Studio 2015 Beta (cgemm3mx, cgemmx, dgemmx, dzgemmx, scgemmx, sgemmx, zgemm3mx, zgemmx). The 32-bit and 64-bit results agreed, and were the same as those from Parallel Studio 13.1. The output, concatenated in alphabetical order of the source files, is attached.

Putting the computer to sleep and running the programs after resuming gave the same results.

Therefore, we need from you the complete reproducers (example source codes, OS, platform) that you found to "not work". It is not clear what you mean by "do not work".

[Robert_C_2]

1. The problem with using one of the example Gemm routines in the MKL library as a test case is that the dimensions of the matrices are too small.   I have found that the problem does not occur if the matrix dimension is less than 8.
2. I have attached a very simple Fortran program test_mkl.f  that illustrates the problem.
3. These are the exact steps I have taken:
   1. Compile and link the program from the command prompt (Intel Fortran Composer XE 2013 SP1 Intel 64 Visual Studio) using ifort/Qmkl test_mkl.f.
   2. Run the executable test_mkl.exe. It will complete.
   3. Put the computer in sleep or hibernation mode.
   4. Wake the computer up.
   5. Run test_mkl.exe again.  It will hang up and not complete.
4. I have no doubt that that the problem is system dependent.  It happens on my Dell desktop but not on my Dell laptop. 
5. Here are the specifications for my Dell desktop:
   1. Dell XPS 8500
   2. Windows 7 64 bit operating system
   3. 8 Intel Core i7-3770 CPUs 3.40 Ghz
   4. 16 Gb RAM
6. The problem is also dependent on the case of the GEMM routine.  I have found that DGEMM always works properly, but CGEMM and ZGEMM do not.  A recent compiler update changed the status of SGEMM from not working to working properly.
7. I have found that a 32 bit executable will work properly, but I get an internal compiler error (C0000005) if I try to rebuild a 32 bit executable after awakening from sleep mode.

[Ying_H_Intel]

Hi Robert, 

Thanks a lot for the test case.  I did try on my laptop with it, can't reproduce the problem. I will escalate to the whole mkl team and see if any one has idea about this. 

Thanks

Ying

[Ying_H_Intel]

Hi Robert, 

Could you please run the below command in command windowss ( intel Fortran Composer XE 2013 SP1 Intel 64 Visual Studio))

> set > beforeH.txt

and after hibernate, 

> set >AfterH.txt

and copy the beforeH.txt and AfterH.txt to me?

Thanks

Ying

[Robert_C_2]

Since the problem is obviously system dependent, is there anyone with a Dell XPS 8500 desktop who can try the GEMM Blas routine after waking from sleep/hibernation to see if it works for them?

The problem only occurs with the complex versions (i.e., CGEMM or ZGEMM, not SGEMM or DGEMM) and only with the 64-bit Fortran compiler (not the 32-bit compiler).