Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
Announcements
Welcome to the Intel Community. If you get an answer you like, please mark it as an Accepted Solution to help others. Thank you!

Slow fortran compilation

Petrov__Sergey
Beginner
677 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
Black Belt
647 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

21 Replies
mecej4
Black Belt
635 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 .

jimdempseyatthecove
Black Belt
635 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

mecej4
Black Belt
635 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).

jimdempseyatthecove
Black Belt
635 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

JohnNichols
Valued Contributor II
635 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

mecej4
Black Belt
635 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.

Petrov__Sergey
Beginner
635 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?

 

Petrov__Sergey
Beginner
635 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?

JohnNichols
Valued Contributor II
635 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. 

mecej4
Black Belt
648 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

Petrov__Sergey
Beginner
635 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

Steve_Lionel
Black Belt Retired Employee
635 Views

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

Petrov__Sergey
Beginner
635 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?)

andrew_4619
Honored Contributor I
635 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

 

 

 

Petrov__Sergey
Beginner
635 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!

Steve_Lionel
Black Belt Retired Employee
635 Views

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

mecej4
Black Belt
635 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] 

Steve_Lionel
Black Belt Retired Employee
635 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."

mecej4
Black Belt
635 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.

Steve_Lionel
Black Belt Retired Employee
277 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.

Reply