Hi to everybody,

I am still quite puzzled by my problems with the compilation of my
programs in different Debian releases, thus I have made a simple test
program to check what is really happening.

The program, that is enclosed below, is quite short. It defines a
reasonably large matrix (mat, dimensions 15000x15000), a vector
(eigval, dimension 15000) and a scratch vector (work, dimension
1600000). Then the program defines a random seed and a working
dimension dim (dim = 5000 in the example) and fills the lower half of
a dim x dim matrix with random numbers between zero and one. Finally the
matrix is diagonalized using lapack subroutine dsyev assuming that it
is symmetric.

program test_comp
c
implicit none
c
integer lda
parameter(lda = 15000)
c
integer scrtch
parameter(scrtch = 1600000)
c
double precision mat(lda,lda)
double precision work(scrtch)
double precision eigval(lda)
c
integer dim, i, j
integer info, lwork
c
c read*, dim
dim = 5000
c
call srand(299934)
c
do i = 1, dim
do j = i, dim
mat(j,i) = rand()
enddo
enddo
c
lwork = -1
c
call dsyev('N', 'L', dim, mat, lda, eigval, work, -1, info)
c
print*, '# info = ', info, ' work dim = ', work(1)
lwork = work(1)
if (lwork.gt.scrtch) stop 'too large scratch required'
c
call dsyev('N', 'L', dim, mat, lda, eigval, work, lwork, info)
c
print*, '# info = ', info
c
do i = 1, dim
write(*,*) i, eigval(i)
enddo
c
end



I enclose the program so that if someone is interested can chek my
results compiling it. The compilation is quite simple if lapack is
installed and should be as follows

gfortran test_compiler.f -llapack.

My point is the following:

If I compile and run this simple program in a server where Squeeze has
been installed (same machine and compiler than in the previous
message)

squeeze$ time gfortran -o test_compiler_squeeze test_compiler.f -llapack
real 0m19.773s
user 0m17.909s
sys 0m1.864s


squeeze$ time ./test_compiler_squeeze > out_squeeze
real 2m23.260s
user 2m34.230s
sys 0m5.484s


The results for the server with etch are the following:

etch$ time gfortran -o test_compiler_etch test_compiler.f -llapack
real 0m1.399s
user 0m0.048s
sys 0m0.004s

etch$ time ./test_compiler_etch > out_etch
real 2m58.818s
user 2m55.507s
sys 0m1.328s


The output in both cases seems to be equal (good), and the execution
time of the programs are more or less comparable (though I do not
understand how can it be in the squeeze case that the user time is
greater than the real time).

What I find really surprising is the compilation time differences,
that can be approx. a factor of 20 greater in squeeze than in etch
(20s vs 1.4s) . The final program sizes are of the same order

-rwxr-xr-x 1 user rsrchrs 8.0K Oct 25 20:29 test_compiler_squeeze*
-rwxr-xr-x 1 user rsrchrs 11K Oct 25 20:29 test_compiler_etch*


If I try to compile the program in my desktop (also squeeze in it) the
program takes a long time to compile, soaks most of my memory (2 GB)
and the mouse and keyboard react very slowly in the meantime.

I find this behavior amazing and I would like to understand what's the
reason for this.

From htop, the process where the squeeze computer spends most of the
time is while linking the program:

/usr/bin/ld --build-id --eh-frame-hdr -m elf_i386 --hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o test_compiler_squeeze /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.4.5/../../../../lib/cr