- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The newer versions of Intel Fortran have Inter-procedural Optimizations enabled by default. Try turning this optimization off (at least inter-file).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 .
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 picture
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm going to guess that the A in XERBLA is in column 73.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can also read my blog post on Fortran source form: Doctor Fortran in "Source Form Just Wants to be Free"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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."
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page