Skip to content

Problem building R with Intel MKL v10 BLAS

9 messages · Michael Braun, Brian Ripley, Hin-Tak Leung +1 more

Original
Michael Braun
# 
NO

Hi.  I'm not sure if this is an R-help or R-devel problem, so I'm 
starting here in the hope that someone can help (and willing to go to 
the other list if it's more appropriate).  I think I am following all of 
the instructions in the various manuals, but clearly I am missing something.

I have an Intel EM64T Dell with 2 dual-core Xeon processors running Red 
Hat EL5.  I would like to build R 2.6.1 with lots of debugging and 
profiling options, and link it to the processor-specific Intel MKL blas. 
The problem is that after I compile R, and do R CMD config BLAS_LIBS, 
the response is
-L/usr/local/lib64/R/lib -lRblas.

This tells me that R is not linked to the Intel BLAS at all.

My config.site file for R is:

#! /bin/sh

R_PAPERSIZE=letter
CFLAGS="-g -O2 -p -pg"
CPPFLAGS="-I/opt/intel/mkl/10.0.1.014/include -I/usr/include 
-I/usr/local/include"
LIBnn=lib64
BLAS_LIBS="-L/opt/intel/mkl/10.0.1.014/lib/em64t -Wl,--start-group 
-lmkl_gf_lp64.so -lmkl_gnu_thread.so -lmkl_core.so -l -l -l -Wl, 
--end-group -lguide -lpthread -lm"

I have set the CONFIG_SITE environment variable to the location of the 
config.site.file.
I am doing everything as superuser.

The command I am using for configure is

./configure --disable-R-profiling --with-blas=no

following the instructions in the R-admin file regarding enabling 
C-level profiling and linking to the external BLAS libraries referenced 
in the config.site file.

The BLAS_LIBS files are different than in the R-admin manual because of 
changes in the Intel MKL for version 10.  These libraries, in this 
order, were taken from the Intel MKL for Linux User's Guide, chapter 5.

So, still no luck linking to the optimized BLAS.  I'd appreciate any 
suggestions.

Thanks,

Michael
Brian Ripley
#
On Thu, 24 Jan 2008, Michael Braun wrote:

            

      
      
      
    

        
Definitely R-devel.

            

      
      
      
    

        
Not so, because Rblas contains any links to an external BLAS.  Check over 
the R-admin manual and note that --enable-BLAS-shlib is the default.
So you need to check

ldd /usr/local/lib64/R/lib/libRblas.so

to see if it linked to MKL.

Check over config.log to see what happened: a common problem is that the 
libraries are not known to ld.so (you may need to include 
/opt/intel/mkl/10.0.1.014/lib/em64t in LD_LIBRARY_PATH)

            

      
      
      
    

        
What compilers are you using?  That would appear to be using 
gcc/gfortran and not the Intel compilers.

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hin-Tak Leung
    

    

      
      #
    

  


  

      
This part "-lmkl_gf_lp64.so -lmkl_gnu_thread.so -lmkl_core.so"
looks wrong - it should be "-lmkl_gf_lp64 -lmkl_gnu_thread -lmkl_core"
without the ".so" part.

I don't know how BLAS_LIBS does it, but when I was linking against
mkl 9, all I did which different from the usual build (diff from the
two rpm spec file I wrote) was 3 changes:

export LDFLAGS=...  -L/opt/intel/mkl/9.1/lib/em64t/
export FFLAGS=... -ff2c
./configure ... --with-blas="-lmkl -lguide -lpthread"

The FFLAGS ezport was needed because of difference between g77 and 
gfortran.

        
Michael Braun wrote:

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Michael Braun
    

    

      
      #
    

  


  

      
NO

Thanks for everyone's help.  Unfortunately, still no success.  So I took 
the alternate route suggested in section A.3.1.5 of R-admin, and just 
created a symbolic link from libRblas.so to .../libmkl_gf_lp64.so.  I 
can still multiply 2 matrices together in R, so it looks like this is 
working.  Can you propose any other test to be sure?

Should I make a similar link for LAPACK?

I'm still perplexed as to why configure couldn't find the MKL BLAS, but 
I suppose any solution that works is a good one.

Thanks again.

Michael

        
Hin-Tak Leung wrote:

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Fri, 25 Jan 2008, Michael Braun wrote:

        

            

      
      
      
    

        
Run 'make check' ... it includes some tests specifically for working 
BLAS.

            

      
      
      
    

        

  
    

      
      
    

  


  


      

    

    
3 days later

    

      
      

        


  

        

      Hin-Tak Leung
    

    

      
      #
    

  


  

      
Prof Brian Ripley wrote:

            

      
      
      
    

        
<snipped>

That reminds me of a discussion I had with our IT guy regarding building 
R 2.5.0 against MKL 8. He had MKL 8.0 against 2.4.x previously and it is
actually faster than 9.x ; but he was having trouble upgrading to R
2.5.0 (with MKL 8).

It turns out that R 2.5.0 added a couple of checks for some
double-complex BLAS/LAPACK routines (I can't remember which), which are 
missing in MKL8, so it is a fact that R 2.5.0 won't build against MKL 8 
- but will build against MKL 9, and once you have built 2.5.0 against 
MKL9, you can swap the libraries (somewhat dangerously) to get the speed
of MKL8 back...

It is not unthinkable that some more checks are added in 2.6.x and
MKL 10 is not passing them... one needs the result of config.log to be sure.

  
  


  


      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
On Mon, 28 Jan 2008, Hin-Tak Leung wrote:

        

            

      
      
      
    

        
Looking at the svn logs, the last change to the BLAS configure tests was 
in Nov 2005.

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Hin-Tak Leung
    

    

      
      #
    

  


  

      
Prof Brian Ripley wrote:

            

      
      
      
    

        
That would be in the R 2.2 <-> R 2.3 time frame (maybe our IT guys was 
having problem jumping from 2.2 to 2.5)... Anyway, I am quite sure about
the R 2.5 + MKL 8 failure as I had looked at the config.log myself then.
To see what's wrong with the original poster's set up one needs to look
at the config.log .

  
  


  


      

    

    

      
      

        


  

        

      Ei-ji Nakama
    

    

      
      #
    

  


  

      
Hi.

2008/1/25, Michael Braun <braunm at mit.edu>:

            

      
      
      
    

        
I have an AMD 64x2 Debian(etch)
$ gcc-4.2 -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../gcc-4.2.2/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang
--prefix=/usr/local/gcc-4.2.2 --enable-shared --disable-multilib
--with-system-zlib --without-included-gettext --enable-threads=posix
--enable-nls --program-suffix=-4.2 --enable-__cxa_atexit
--enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr
--enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.2.2

MKL_LIB_PATH=/opt/intel/mkl/10.0.1.014/lib/em64t
MKL="   -L${MKL_LIB_PATH}                               \
        -Wl,--start-group                               \
                ${MKL_LIB_PATH}/libmkl_gf_lp64.a        \
                ${MKL_LIB_PATH}/libmkl_gnu_thread.a     \
                ${MKL_LIB_PATH}/libmkl_core.a           \
        -Wl,--end-group                                 \
        -liomp5 -lguide -lpthread -lgomp"

./configure CC=gcc-4.2\
        CXX=g++-4.2\
        F77=gfortran-4.2\
        FC=gfortran-4.2\
        --with-lapack="$MKL" --with-blas="$MKL"

mkl_core seemed to want to cause libiomp5. dgemm gave a funny result
in matrix of 1000x1000 if I did not link with real libiomp5.