MKL DFTI Linking Takes Forever

[evankw21]

I started a thread relative to this issue on the IVF Forum. After a lot of detective work, we found the problem is related to the MKL_DFTI code, and Steve indicated I should address the problem here. For all the gory details, the name of the thread over there was "Linking Takes Too Long".

The problem is that, using Windows IVF, my projects take several minutes to link. I made a short program that exhibited the same behavior. I've noticed a lot of other people having trouble figuring out how to link to the MKL_DFTI routines, so I'm wondering if I'm doing it wrong. I just figured out one way to make it compile and link, but it may not be the best way.

Here's the sample program that takes two minutes to link. See comments after several of the lines for how the behavior changes as I try different things.

The culprit seems to be in mkl_dfti, specifically DftiCreateDescriptor.

program Console1
implicit none
integer :: nfft=16
real :: pser(16)
complex :: spec1(9)

call r2c_fwd_fft(pser,4,spec1)
! If above call is commented out, the program links quickly. If present, linking takes several minutes

print *, 'Hello World'

end program Console1

subroutine r2c_fwd_fft(rts,nord,cspec)

use MKL_DFTI
! If above line is commented out, I get:
! Error 1 error #6457: This derived type name has not been declared. &
! [DFTI_DESCRIPTOR] E:\Evan\ifort\Console1\Console1.f90 48
! I copied mkl_dfti.f90 from "D:\Program Files\Intel\Compiler\11.1\048\mkl\include" to the source directory for this
! project

! If I don't have the Fortran => Libraries => Use Intel Math Kernel Library set to "Sequential...", then I get:
! Error 1 error LNK2019: unresolved external symbol _dfti_create_descriptor_1d &
! referenced in function _R2C_FWD_FFT. Console1.obj

implicit none

real :: rts(:)
integer :: nord,nfft
complex :: cspec(:)
type(DFTI_DESCRIPTOR), POINTER :: My_Desc1_Handle
Integer :: Status(6)=0

nfft=2**nord
Status(1) = DftiCreateDescriptor(My_Desc1_Handle, DFTI_SINGLE, DFTI_REAL, 1, nfft)
! This is the line that causes the linker to be very slow. Without the above line, but with
! the following 5 lines, the linker is fast.

!Status(2) = DftiSetValue( My_Desc1_Handle, DFTI_PLACEMENT, DFTI_NOT_INPLACE)
!Status(3) = DftiSetValue(My_Desc1_Handle,DFTI_CONJUGATE_EVEN_STORAGE,DFTI_COMPLEX_COMPLEX) ! Default, optional
!Status(4) = DftiCommitDescriptor(My_Desc1_Handle)
!Status(5) = DftiComputeForward(My_Desc1_Handle, rts(1:nfft), cspec(1:nfft/2+1))
!Status(6) = DftiFreeDescriptor(My_Desc1_Handle)

if (sum(Status) /= 0) then
print*,'r2c_fwd_fft Warning: sum(Status(1:6)) /= 0 from MKL'
print*,' Status(1:6) = ',Status(1:6)
endif

return
end subroutine

[Vadim_M_Intel]

Setting "Linker->Optimization->Interprocedural Optimization" to "No" value should help.

[Dmitry_B_Intel · Accepted solution]

Hi Evan,

Thank you for posting this problem at MKL Forum!
As the IVF topic identified, the time is taken by xilink, and can be fixed by turning off IPO for the linker.

I have a couple of other comments that you might find useful.

Firstly, you seem to link your application statically (..., mkl_core.lib, libiomp5mt.lib). You can drastically reduce linking time by linking dynamically (..., mkl_core_dll.lib, libiomp5md.lib). Though it may not be acceptible for release, this may help in development.

Secondly,the Fortran application using mkl_dfti gets rather large when linked statically because it links in both double and single precision code, even if you only use DFTI_SINGLE. This is a feature of DFTI. You can reduce the size of application (and the linking time a bit) by replacing statement
USE DFTI
with
USE MKL_DFTI, FORGET=>DFTI_SINGLE, DFTI_SINGLE=>DFTI_SINGLE_R
(you can find a notice explaining this feature in both MKL Reference Manual and in the file mkl_dfti.f90).

Thanks
Dima

[evankw21]

Quoting - Dmitry Baksheev (Intel)

Hi Evan,

Thank you for posting this problem at MKL Forum!
As the IVF topic identified, the time is taken by xilink, and can be fixed by turning off IPO for the linker.

I have a couple of other comments that you might find useful.

Firstly, you seem to link your application statically (..., mkl_core.lib, libiomp5mt.lib). You can drastically reduce linking time by linking dynamically (..., mkl_core_dll.lib, libiomp5md.lib). Though it may not be acceptible for release, this may help in development.

Secondly,the Fortran application using mkl_dfti gets rather large when linked statically because it links in both double and single precision code, even if you only use DFTI_SINGLE. This is a feature of DFTI. You can reduce the size of application (and the linking time a bit) by replacing statement
USE DFTI
with
USE MKL_DFTI, FORGET=>DFTI_SINGLE, DFTI_SINGLE=>DFTI_SINGLE_R
(you can find a notice explaining this feature in both MKL Reference Manual and in the file mkl_dfti.f90).

Thanks
Dima

Dmitiry and Vadim:

Thanks for your responses. Turning off IPO in the Linker did indeed fix the problem. Yeah!!

I'm afraid I wasted some of Steve's time because I was told to do that in my previous thread and could have sworn that I did it, but when I checked today, the Linker IPO setting was set to "Yes". I think I must have been looking at the IPO setting in the Fortran tab instead of the Linker tab.

How do you set whether you link via the static libraries or the dynamic libraries, and how do you decide which you want to do? I guess that's in the Linking 101 course, but I'm not up on that.

Thanks again.

Evan

[Dmitry_B_Intel]

Evan,

Fortran->Libraries->Runtime Library contains a list of configurations, pick one with DLL to set dynamic linking.

Regardingdecision when to use dynamic or static, I typically use static linking only if I want to run the application on another machine (where the dynamic libraries are not available). As long as you stay on the same machine dynamic linking should be just fine(provided that the location of the dynamic libraries used by the application is known to the system, i.e. in the PATH).

Thanks
Dima

[evankw21]

Quoting - Dmitry Baksheev (Intel)

Evan,

Fortran->Libraries->Runtime Library contains a list of configurations, pick one with DLL to set dynamic linking.

Regardingdecision when to use dynamic or static, I typically use static linking only if I want to run the application on another machine (where the dynamic libraries are not available). As long as you stay on the same machine dynamic linking should be just fine(provided that the location of the dynamic libraries used by the application is known to the system, i.e. in the PATH).

Thanks
Dima

That makes sense. Thanks!