From paciorek at hsph.harvard.edu  Fri Apr 18 14:53:26 2008
From: paciorek at hsph.harvard.edu (Christopher Paciorek)
Date: Fri, 18 Apr 2008 08:53:26 -0400
Subject: [Rd] configure can't find dgemm in MKL10
Message-ID: <4808611D.10CD.002E.0@hsph.harvard.edu>

Hi, 
I'm trying to follow the R-admin instructions for using MKL10 as the external BLAS compiling R-2.6.2 under Linux on a RH EL head node of a cluster.  The configure process seems to have problems when it checks for dgemm in the BLAS.  I'm using configure as:
 ./configure CC=icc F77=ifort --with-lapack="$MKL" --with-blas="$MKL"  where $MKL is defined as in R-admin section A.3.1.4.

checking for cblas_cdotu_sub in vecLib framework... no
checking for dgemm_ in    -L/usr1/util/Intel/mkl/10.0.1.014/lib/em64t                                            -Wl,--start-group                                                    /usr1/util/Intel/mkl/10.0.1.014/lib/em64t/libmkl_gf_lp64.a                             /usr1/util/Intel/mkl/10.0.1.014/lib/em64t/libmkl_gnu_thread.a                          /usr1/util/Intel/mkl/10.0.1.014/lib/em64t/libmkl_core.a                        -Wl,--end-group                                              -liomp5 -lguide -lpthread -lgomp... no
checking for dgemm_... no
checking for ATL_xerbla in -latlas... yes
checking for dgemm_ in -lf77blas... no
checking for dgemm_ in -lblas... yes
checking for dgemm_ in -ldgemm... no
checking for dgemm_ in -lblas... (cached) yes
checking for dgemm_ in -lessl... no
checking for dgemm_ in -lblas... (cached) yes

I've looked in the MKL .a files and do not actually see dgemm or dgemm_ explicitly.  So this seemingly explains the result of configure which is that BLAS_LIBS is not set to point to MKL but defaults to pointing to the usual Rblas (based on BLAS_LIBS in Makeconf (BLAS_LIBS = -L$(R_HOME)/lib$(R_ARCH) -lRblas) and the absence of a mention of BLAS in the 'External libraries' line at the end of the configure process output.

In looking for dgemm in the MKL .a files (ar t libName.a | grep dgemm),
libmkl_gf_lp64.a lists cblas_dgemm_lp64.o,_dgemm_lp64.o
libmkl_core.a lists a bunch of things with dgemm in the name but not dgemm itself, e.g., _dgemm_kernel_0_fb.o,_mc_dgemm_bufs_0.o
libmkl_gnu_thread.a lists dgemm_omp.o

Incidentally _dgemm.o is listed in libmkl_gf_ilp64.a.  

We're running Red Hat Enterprise Linux AS release 4 (Nahant Update 5) on an Intel Xeon head node of a cluster.

Incidentally, this has come about because in playing with my new $1300 Macbook, I found it was doing basic matrix work (dense matrix multiplication, Cholesky) about 5x as fast as our Linux cluster.  I haven't looked into it much, but given that CPU use is listed as nearing 200% on the dual core Mac, part of this may be due to the Mac taking advantage of both cores. My hope is that with a faster BLAS the difference between the Mac and our cluster for basic linear algebra will lessen or disappear.

Any tips on what may be going wrong in the configure test process or how to get around this would be helpful.  

Thanks,
Chris

----------------------------------------------------------------------------------------------
Chris Paciorek / Asst. Professor        Email: paciorek at hsph.harvard.edu
Department of Biostatistics             Voice: 617-432-4912
Harvard School of Public Health         Fax:   617-432-5619
655 Huntington Av., Bldg. 2-407         WWW: www.biostat.harvard.edu/~paciorek
Boston, MA 02115 USA                    Permanent forward: paciorek at alumni.cmu.edu



[Rd] configure can't find dgemm in MKL10
Christopher Paciorek