Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Slow fortran compilation

Petrov__Sergey
Beginner
2,051 Views

Hi,

I'm trying to compile LAPACK library with Fortran compiler but the compilation time is about few hours... Even from LAPACK_tutorial video it is clear that it should not take so much time to be compiled. What is the possible reason for my problem?

I use:

Windows 7x64

Intel Parallel Studio XE 2020 with Microsoft Visual Studio 2017

0 Kudos
1 Solution
mecej4
Honored Contributor III
2,021 Views

Petrov, Sergey wrote:
... the compilation output tells me that 1 of 4 task is completed with error "error LNK2001: unresolved external symbol XERBL        sorhr_col.obj".

There is a subroutine called XERBLA, which is used for reporting errors in BLAS and Lapack routines. See if a typographical error caused XERBLA to be read as XERBL in the source file sorhr_col.f in the Lapack SRC directory.

Petrov, Sergey wrote:
How to use flags like /Qxhost /fpp /nologo /Qvec-threshold:80 in Visual Studio? What this flag means?

You do not have to use these flags. I reported the flags because compilation time is affected by the code generation and optimization options that are in effect. 

See https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-alphabetical-list-of-compiler-options .

View solution in original post

0 Kudos
21 Replies
mecej4
Honored Contributor III
1,896 Views

The time to build Lapack will depend on the versions of Lapack and the Fortran compiler used, the compiler options specified, the nature of the build platform (CPU, memory size, OS, disk throughput)  and the selection of the parts of Lapack that are to be compiled.

Do you have a purpose in undertaking this exercise? The MKL component that is supplied with IFort contains BLAS and Lapack already.

If you want libraries based on public-domain sources, you can obtain them at http://icl.cs.utk.edu/lapack-for-windows/lapack/#libraries_intel .

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,896 Views

The newer versions of Intel Fortran have Inter-procedural Optimizations enabled by default. Try turning this optimization off (at least inter-file).

Jim Dempsey

0 Kudos
mecej4
Honored Contributor III
1,896 Views

As a test, I downloaded the Lapack 3.9 sources from Netlib and built the Lapack library (just Lapack, not including reference BLAS or running tests). 

I used /Qxhost /fpp /nologo /Qvec-threshold:80 as the compiler option, and built on Windows 10-64 using IFort 19.1.0.166 on a PC with an i5-8400 CPU. The build of the library took 350 seconds (about 6 minutes).

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,896 Views

One of the issues with prior compilers was for systems that used the Intel License Manager where the license(s) are managed on a remote system. Maybe then problem has returned. Try searching this forum for License Manager using google with:

      "license manager" site:software.intel.com

Jim Dempsey

0 Kudos
JohnNichols
Valued Contributor III
1,893 Views

mecej4 wrote:

As a test, I downloaded the Lapack 3.9 sources from Netlib and built the Lapack library (just Lapack, not including reference BLAS or running tests). 

I used /Qxhost /fpp /nologo /Qvec-threshold:80 as the compiler option, and built on Windows 10-64 using IFort 19.1.0.166 on a PC with an i5-8400 CPU. The build of the library took 350 seconds (about 6 minutes).

A core i5- 8400 has a passmark rank of 303 so it is a reasonable processor, were you using an SSD? 

John

0 Kudos
mecej4
Honored Contributor III
1,896 Views

Nichols, John wrote:

Quote:

A core i5- 8400 has a passmark rank of 303 so it is a reasonable processor, were you using an SSD? 

No, the source and object files were all located on a Ramdisk.

0 Kudos
Petrov__Sergey
Beginner
1,896 Views

Thank you for answers and sorry I've been missed for few days,

The solution I found on this forum is to remove LM_LICENSE_FILE environment variable (I had it).

Now the building time much faster (I can be mistaken but I think it is about 35 minuts) and the compilation output tells me that 1 of 4 task is completed with error "error LNK2001: unresolved external symbol XERBL        sorhr_col.obj". I do not use SSD. Windows 10 x64, intel i5.

How to use flags like /Qxhost /fpp /nologo /Qvec-threshold:80 in Visual Studio? What this flag means?

 

0 Kudos
Petrov__Sergey
Beginner
1,896 Views

By the way I need LAPACK to use it in Armadillo. Is it possible to replace LAPACK by MKL and use tha latest in Armadillo?

0 Kudos
JohnNichols
Valued Contributor III
1,893 Views

mecej4 wrote:

Quote:

Nichols, John wrote:

 

Quote:

A core i5- 8400 has a passmark rank of 303 so it is a reasonable processor, were you using an SSD? 

 

No, the source and object files were all located on a Ramdisk.

So about 4 times faster than an SSD 

Not bad. 

0 Kudos
mecej4
Honored Contributor III
2,022 Views

Petrov, Sergey wrote:
... the compilation output tells me that 1 of 4 task is completed with error "error LNK2001: unresolved external symbol XERBL        sorhr_col.obj".

There is a subroutine called XERBLA, which is used for reporting errors in BLAS and Lapack routines. See if a typographical error caused XERBLA to be read as XERBL in the source file sorhr_col.f in the Lapack SRC directory.

Petrov, Sergey wrote:
How to use flags like /Qxhost /fpp /nologo /Qvec-threshold:80 in Visual Studio? What this flag means?

You do not have to use these flags. I reported the flags because compilation time is affected by the code generation and optimization options that are in effect. 

See https://software.intel.com/en-us/fortran-compiler-developer-guide-and-reference-alphabetical-list-of-compiler-options .

0 Kudos
Petrov__Sergey
Beginner
1,896 Views

mecej4 wrote:

There is a subroutine called XERBLA, which is used for reporting errors in BLAS and Lapack routines. See if a typographical error caused XERBLA to be read as XERBL in the source file sorhr_col.f in the Lapack SRC directory.

I checked file SRC/sorhr_col.f but it contains the word "XERBLA ". But the error is XERBL. See attached pictureXERBLA.png

0 Kudos
Steve_Lionel
Honored Contributor III
1,896 Views

I'm going to guess that the A in XERBLA is in column 73.

0 Kudos
Petrov__Sergey
Beginner
1,897 Views

Steve Lionel (Ret.) (Blackbelt) wrote:

I'm going to guess that the A in XERBLA is in column 73.

ahah yes :) how did you know that and what does that mean?)

0 Kudos
andrew_4619
Honored Contributor II
1,897 Views

In fixed format Fortran characters after 72 are ignored. Long lines need to use "continuation" lines. You would need to read a basic fortran book to learn such things. There  are some basic on this page from a google search https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html

 

 

 

0 Kudos
Petrov__Sergey
Beginner
1,897 Views

andrew_4619 wrote:

In fixed format Fortran characters after 73 are ignored. Long lines need to use "continuation" lines. You would need to read a basic fortran book to learn such things. There  are some basic on this page from a google search https://web.stanford.edu/class/me200c/tutorial_77/03_basics.html

 

 

 

tank you! very interesting

Actually I'am not familiar with fortran yet

I deleted some spaces in line that contains XERBLA and it compiled without any error!

Thank all of you for your help!

0 Kudos
Steve_Lionel
Honored Contributor III
1,897 Views

You can also read my blog post on Fortran source form: Doctor Fortran in "Source Form Just Wants to be Free"

0 Kudos
mecej4
Honored Contributor III
1,897 Views

Petrov, Sergey wrote:
I deleted some spaces in line that contains XERBLA and it compiled without any error!

When compiling a large package such as Lapack, a newcomer to Fortran should be careful about "fixing" things that are not "broken". The following short program captures the issue. Try to compile and link with and without the /warn option.

      program tst
*2345678901234567890123456789012345678901234567890123456789012345678901234
      implicit none
      call                                                          xerbla
      end program

Unfortunately, the current compiler (19.1.0.166) with /warn emits a partly incorrect warning:

xer.f(3): warning #8889: Explicit declaration of the EXTERNAL attribute is required.   [XERB] 

0 Kudos
Steve_Lionel
Honored Contributor III
1,897 Views

Why do you think the warning is incorrect? Perhaps you're not aware that 19.1 added /warn:external, to go along with Fortran 2018's IMPLICIT NONE(EXTERNAL). When you just say /warn, that turns it on, causing the compiler to complain if you reference a procedure without declaring it EXTERNAL. Or are you thinking that an explicit interface doesn't do that? It does.

An interface body in a generic or specific interface block specifies the EXTERNAL attribute and an explicit specific interface for an external procedure, dummy procedure, or procedure pointer.

I will agree that the message, as currently worded, would probably encourage people to use EXTERNAL rather than explicit interfaces and would prefer a different wording. I just submitted a request for different wording - I suggested "Explicit interface or EXTERNAL declaration required."

0 Kudos
mecej4
Honored Contributor III
1,897 Views

Steve, Ifort 19.1 emits the #8889 warning, wording it with "... is required" even when one of /stand:f95, /stand:f03 or /stand:f08 is specified. This is a departure from how Ifort 19.0.5 treats the same code.

0 Kudos
Steve_Lionel
Honored Contributor III
1,539 Views

19.0.5 didn't support /warn:external. Similar to how /warn:declarations implies IMPLICIT NONE, /warn:external implies IMPLICIT NONE(EXTERNAL). This is independent of /stand, since nothing in any of these standards requires an EXTERNAL attribute otherwise. /stand tells the compiler to report deviations from syntax and constraints specified in those standards - this isn't one of those.

0 Kudos
Reply