Large size of fortran executable when compiling with intel MKL

[Zahraa_Ibrahim]

Sorry if my thread appears twice, but I was not logged in when I sent it the first time, and as I don't know if that is an issue or not, I am resending it after logging in.

Hello
I am running on linux redhat enterprise v.7. Previously, I was compiling my fortran 90 programs with the lahey fujitsu compiler and statically linking to the lapack and blas libraries that came with the lahey version. The size of the executable was about 2 MB.

Now using the intel fortran 11 and the MKL 10 libraries I am ending up with a 5.6 MB executable, which hinders me from loading any other program into memory.
I chose to link to the static libraries lmkl_intel, lmkl_sequential, lmkl_core.
(my intel compiler options are -free -02 -heap-arrays 0 )

What is the cause of that increase, and can I reduce that size?
I need the program to be statically linked.

Thanks
Zahraa

[TimP]

I'm not clear on whether you are comparing a partially static linked build with the older compiler agains a fully static linked build. With ifort 11, you have options to link some or all Intel libraries statically, while leaving the linux libraries dynamic linked. It would seem from your description that -static-intel should do it.

[Zahraa_Ibrahim]

Quoting - tim18

I'm not clear on whether you are comparing a partially static linked build with the older compiler agains a fully static linked build. With ifort 11, you have options to link some or all Intel libraries statically, while leaving the linux libraries dynamic linked. It would seem from your description that -static-intel should do it.

Thanks for your reply, Tim
I am not sure what/or where the linux libraries are, but I think I was fully statically linking in both cases.
Here are the relevant lines in my make file in both cases:

Case of lapack libraries from lahey/Fujitsu Fortran with resulting executable about 2 MB
SHELL = /bin/sh
FC = lf95
CC = gcc
FOPT = -O --nfix --ntrace --nchk --tp4 --block 8192
LDFLAGS = -L/usr/local/lf9562/lib -static
R_LIBS = -llapackmt -lblasmtp4

Case of the intel libraries with resulting executable about 5.6 MB
SHELL = /bin/sh
FC = /opt/intel/Compiler/11.0/074/bin/ia32/ifort
CC = gcc
FOPT = -free -O2 -heap-arrays 0
LDFLAGS = -L/opt/intel/Compiler/11.0/074/mkl/lib/32 -L/opt/intel/Compiler/11.0/074/lib/ia32 -static
R_LIBS = -lmkl_intel -lmkl_sequential -lmkl_core -lmkl_sequential -lmkl_core -lpthread

I tried the -static-intel option, which decreases the size to below 2 MB, but as I am exporting my executable to different systems it is not the solution I am opting for.

Zahraa

[TimP]

Quoting - Zahraa Ibrahim

I tried the -static-intel option, which decreases the size to below 2 MB, but as I am exporting my executable to different systems it is not the solution I am opting for.

The usual solution is to link with -static-intel on the oldest glibc you will support, e.g. CentOS 3.9 (with binutils updated as necessary), requiring newer systems to have compat libraries installed. If you must support Red Hat 9 or earlier, you have a bit of my sympathy, but your customers don't.

[Zahraa_Ibrahim]

Quoting - tim18

The usual solution is to link with -static-intel on the oldest glibc you will support, e.g. CentOS 3.9 (with binutils updated as necessary), requiring newer systems to have compat libraries installed. If you must support Red Hat 9 or earlier, you have a bit of my sympathy, but your customers don't.

Thanks Tim
I am my sole customer fortunately, so am dealing with only my own and my computers complaints.

About using the -static-intel option? I thought it suffices to state:
-L -static-intel -lmkl_intel -lmkl_sequencial -mkl_core -lmkl_intel -lmkl_sequencial -mkl_core -lpthread
but found that this actually links to the dynamic mkl libraries. (Therefore the 1 MB executable). Of course my other machines complained about not finding the libmkl_intel.so and all the other mkl libraries.
I had to specifically write down the full path to every one of those static mkl libraries, but it worked finally on all the machines. The main point is however that in that case I got a 5.1 MB executable, which is still quite a big executable.

I am beginning to think that using the static mkl libraries (and I have no other option) with more tweeking will not reduce the size much more than that. The question becomes then really, is there a way to reduce the size of the libmkl_core library? For example compiling a less condense library. I am mostly interested in the 'basic' blas and lapack libraries?

Zahraa

[TimP]

Presumably, you had to enter the full pathnames of libmkl_core.a et al. to get static link. Rather than repeating the library names, the documented method is to surround the 3 static mkl libraries by -Wl,--begin-group ... -Wl,--end-group. I doubt it will change your final size.
If it's worth the trouble to you, given that you don't want threading and probably don't exercise nearly the variety of cases for which MKL is optimized, you ought to be able to get close to the performance and greatly improve on the library size by compiling the open source netlib version of the larger functions yourself. Or, the gfortran compatible lapack and blas library source, ifavailable foryour linux,ought to work. Needless to say, code size is not likely to be a criterion for those functions where maximum performance is demanded from MKL.
I assumed that you wanted to avoid .so in order to make a self-contained product, as dynamic link usually is no problem when running on the development system.

[Zahraa_Ibrahim]

Quoting - tim18

Presumably, you had to enter the full pathnames of libmkl_core.a et al. to get static link. Rather than repeating the library names, the documented method is to surround the 3 static mkl libraries by -Wl,--begin-group ... -Wl,--end-group. I doubt it will change your final size.
If it's worth the trouble to you, given that you don't want threading and probably don't exercise nearly the variety of cases for which MKL is optimized, you ought to be able to get close to the performance and greatly improve on the library size by compiling the open source netlib version of the larger functions yourself. Or, the gfortran compatible lapack and blas library source, ifavailable foryour linux,ought to work. Needless to say, code size is not likely to be a criterion for those functions where maximum performance is demanded from MKL.
I assumed that you wanted to avoid .so in order to make a self-contained product, as dynamic link usually is no problem when running on the development system.

Thanks, the -Wl, --start-group, ... is a cleaner way, but as expected does not reduce the size.
Yes, I am avoiding the .so if possible. Basically my application needs to diagonalize hundreds of matrices, so it divides them into groups and sends them to my different machines, dual-core, multithreaded, and non threaded ones, which at the moment all run redhat 7. Your suggestion of using the -static-intel option and dynamically linking to the system libraries turned out to work smoothly on my current machines, so it is an option, it does not speeden up my application noticably, but decreases its size a bit.
I purchased the MKL libraries because they solved a problem I had with the pdpotrf routine in the lapack library I was using at the time when dealing with very big matrices. So I am not very eager to test the open source netlib, especially as I am a novice here. I think I will test the performance of my system with the larger files for the moment.
Many thanks for your help
Zahraa