[R] linking R to goto blas
Prof Brian Ripley
ripley at stats.ox.ac.uk
Tue Jun 21 12:08:40 CEST 2005
OTOH, the Opteron Goto BLAS has no such problems on FC3, so I suspect this
is specific to only some of the architectures.
I've added a comment in the R-admin manual that says
It has been reported that on some RedHat-based Linux systems it is
necessary to set @code{OMP_NUM_THREADS=1} in the environment when using
a multi-threaded Goto BLAS, but others run happily with multiple threads.
Note the `when using': it will need to be set whenever R is run.
On Mon, 20 Jun 2005, Stefan Sobernig wrote:
> Dear all,
>
> Finally -- after one week of trial & error -- the fog lifted thanks to
> the hints of Kazushige Goto.
> Therefore, I would like to report back the workaround (for Fedora Core
> based systems, including FC4) to the list and a pre-mature analysis,
> inspired
> by K. Goto:
>
> A brief howto (applicable to and tested on Fedore Core 4, R-2.1.0,
> libgoto 0.99-3):
>
> 1) Get the appropriate GOTO BLAS library for your processor core and
> place it in an arbitrary directory (either /usr/lib or your home directory).
>
> 2) set the environment variable OMP_NUM_THREADS=1 (in bash: "export
> OMP_NUM_THREADS=1")
>
> 3) change to your R source directory and run configure according to your
> needs: pass the following values to the "--with-blas-flag":
> --with-blas="-L</your/path/to/libgoto> -lgoto_xxx-xx-r0.99-3 -lpthread"
> (in my case: --with-blas="-L/usr/lib/ -lgoto_northwood-32-r0.99-3
> -lpthread").
>
> 4) run make & make install
>
> 5) enjoy GOTO performance
>
> BACKGROUND:
>
> According to K. Goto setting OMP_NUM_THREADS=1 results in libgoto not
> using the pthread library, therefore it is running in
> single-thread-mode, while R might still be supporting threads in
> general. He concludes that there is a major incompatibility with pthread
> which might be due to RedHat's/ Fedora's home-brewed (since RH 9)
> reliance on multithreading simulation provided by their Native POSIX
> Thread Library (NLTP). Libgoto as such is not NLTP-compatible according
> to K. Goto. Other distributions (and thread implementations) don't show
> this misbehaviour (on my Debian based system libgoto links perfectly
> without the workaround described above).
>
> Thanks for all your comments and contributions.
>
> //stefan at vienna
>
>
>
> Prof Brian Ripley wrote:
>
>> R already contains a xerbla: you should not be adding one.
>>
>> On Mon, 13 Jun 2005, Stefan Sobernig wrote:
>>
>>> Prof. Ritley, Mr. Dalgaard, thank you very much for the immediate reply
>>> and your efforts!
>>> We investigated a littlle further, though not directly following Mr.
>>> Dalgaard's findings
>>> on dynamic linking. We got aware of another short notice published on
>>> the R-devel list,
>>> providing some hints for installing R and goto (see
>>> http://maths.newcastle.edu.au/~rking/R/devel/03b/1267.html):
>>>
>>>
>>> ############ snip ###################################
>>> [What I did to link R against Goto's BLAS (mostly following Prof. Bates'
>>> instruction):
>>> - Install libgoto*.so and symlink to libgoto.so.
>>> - Download xerbla.f and compile to xerbla.o.
>>> - Run the R configure script with --with-blas="-lgoto
>>> /path/to/xerbla.o".
>>> - Edit Makeconf and delete the path to xerbla.o in BLAS_LIB.
>>> - make; make check
>>> ]
>>> ############ snip ###################################
>>>
>>> * Therefore, we got the auxiliary lapack routine xerbla offered at
>>> http://www.cs.utexas.edu/users/kgoto/libraries/xerbla.c
>>> and compiled it by calling: "gcc -c xerbla.c -o xerbla.o" (please note,
>>> that I am not that expierenced in C programming as such,
>>> my knowledge is limited to deploying and fixing c-coded apps). Am I
>>> right to say that this xerbla extension changes the entry
>>> point of the goto library?
>>>
>>> * Then, we re-configured R using: ./configure --prefix=/usr
>>> --with-blas="-L/usr/lib/ -lgoto_prescott-32-r0.99-3
>>> /home/ssoberni/xerbla.o -lpthread"
>>>
>>> * Unfortunately, this resulted in another error affecting the configure
>>> process so that BLAS_LIBS is set to "-lblas" (pointing to standard blas
>>> libs):
>>>
>>> ########### config.log ################################
>>> configure:32429: gcc -o conftest -g -O2 -I/usr/local/include
>>> -L/usr/local/lib conftest.c -L/usr/lib/ -lgoto_prescott-32-r0.99-3
>>> /home/ssoberni/xerbla.o -lpthread -lg2c -lm -lgcc_s -ldl -lm >&5
>>> /home/ssoberni/xerbla.o(.text+0x0): In function `xerbla_':
>>> : multiple definition of `xerbla_'
>>> /tmp/ccMxAKbu.o(.text+0x0):/home/ssoberni/R-2.1.0/conftest.c:143: first
>>> defined here
>>> /usr/bin/ld: Warning: size of symbol `xerbla_' changed from 5 in
>>> /tmp/ccMxAKbu.o to 43 in /home/ssoberni/xerbla.o
>>> collect2: ld returned 1 exit status
>>> ########### config.log ################################
>>>
>>> We keep on trying ...
>>> Thanks for your thoughts ...
>>>
>>> //stefan
>>>
>>>
>>> Peter Dalgaard wrote:
>>>
>>>> Peter Dalgaard <p.dalgaard at biostat.ku.dk> writes:
>>>>
>>>>
>>>>
>>>>> Stefan Sobernig <stefan.sobernig at wu-wien.ac.at> writes:
>>>>>
>>>>>
>>>>>
>>>>>> Dear all,
>>>>>>
>>>>>> I am currently trying to link R 2.1.0 to the GOTO BLAS 0.99.3
>>>>>> library on
>>>>>> a box running Fedora Core 3 , basically following the steps
>>>>>> indicated in
>>>>>> the R-Admin document:
>>>>>>
>>>>>> 1: I downloaded the current libgoto.xxx.so from
>>>>>> http://www.cs.utexas.edu/users/kgoto/libraries/libgoto_prescott-32-r0.99-3.so.gz,
>>>>>>
>>>>>> a version suitable for our XEON machine (Nocona core), unpacked it to
>>>>>> /usr/lib and created a symlink libgoto.so pointing to the library.
>>>>>>
>>>>>> 2: Then, I got ready to re-configure and re-compile R (2.1.0)
>>>>>> using the
>>>>>> following configure flags: ./configure --prefix=/usr --enable-R-shlib
>>>>>> --enable-shared --with-tcltk --with-blas="-lgoto -lpthread -lm"
>>>>>>
>>>>>>
>>>>> ...
>>>>>
>>>>>
>>>>>> Please, I highly appreciate any thoughts or hints as my colleagues
>>>>>> and I
>>>>>> are eager to get into GOTO's universe.
>>>>>>
>>>>>>
>>>>> Hmm. Looks over-complicated to me. What works for me on AMD64 is to
>>>>> have a config.site file in my BUILD-GOTO directory, containing
>>>>>
>>>>>
>>>>>
>>>>>> cat config.site
>>>>>>
>>>>>>
>>>>> BLAS_LIBS="-L/home/pd/GOTO -lgoto_opt64p-r0.96 -lpthread"
>>>>> CFLAGS="-O3 -g"
>>>>> #CFLAGS="-g"
>>>>> FFLAGS=$CFLAGS
>>>>> CXXFLAGS=$CFLAGS
>>>>>
>>>>> (the .*FLAGS business is optional, of course). With this in place, a
>>>>> simple ../R/configure followed by make seems to do the trick.
>>>>>
>>>>> I'll give it a try on my FC3 system, but it's a 500 MHz PIII, so it
>>>>> takes a while...
>>>>>
>>>>>
>>>>
>>>> Hmm... That gives me the grDevices issue, which boils down to an R
>>>> that segfaults immediately upon startup, in
>>>>
>>>> #0 0x05c0aea7 in tilde_expand () from /usr/lib/libreadline.so.4
>>>> #1 0x08170254 in R_ExpandFileName_readline (
>>>> s=0x8bb4020
>>>> #"/home/pd/r-patched/BUILD-GOTO/library/grDevices/R/sysdata.rdb",
>>>> #buff=0x8295300
>>>> #"/home/pd/r-patched/BUILD-GOTO/library/grDevices/R/grDevices")
>>>> at ../../../R/src/unix/sys-std.c:406
>>>> #2 0x0816f5da in R_ExpandFileName (
>>>> s=0x8bb4020
>>>> #"/home/pd/r-patched/BUILD-GOTO/library/grDevices/R/sysdata.rdb") at
>>>> #../../../R/src/unix/sys-unix.c:129
>>>> #3 0x08167352 in R_FileExists (
>>>> path=0x8bb4020
>>>> #"/home/pd/r-patched/BUILD-GOTO/library/grDevices/R/sysdata.rdb") at
>>>> #stat.h:365
>>>> #4 0x08105da3 in do_fileexists (call=0x84fd544, op=0x82c5f78,
>>>> #args=0x0,
>>>> rho=0x8c514a4) at ../../../R/src/main/platform.c:857
>>>> #5 0x080edc85 in do_internal (call=0x0, op=0x82ba5d4, args=0x3920,
>>>> env=0x8c514a4) at ../../../R/src/main/names.c:1078
>>>> #6 0x080c0daa in Rf_eval (e=0x84fd57c, rho=0x8c514a4)
>>>> at ../../../R/src/main/eval.c:382
>>>> #7 0x080c3695 in Rf_applyClosure (call=0x8668c28, op=0x84fd5b4,
>>>> arglist=0x8c50564, rho=0x8ad5cc4, suppliedenv=0x82aa5f0)
>>>>
>>>> running --no-readline gives me another crash
>>>>
>>>> (gdb) bt
>>>> #0 0x003fb0da in strcmp () from /lib/ld-linux.so.2
>>>> #1 0x003f009a in _dl_map_object () from /lib/ld-linux.so.2
>>>> #2 0x004fdb58 in dl_open_worker () from /lib/tls/libc.so.6
>>>> #3 0x00000000 in ?? ()
>>>>
>>>> ...which suggests that something is up with dynamic linking.
>>>>
>>>> I'll give it another spin...
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Stefan Sobernig
>>> Department of Information Systems and New Media
>>> Vienna University of Economics
>>> Augasse 2-6
>>> A - 1090 Vienna
>>>
>>> Phone: +43 - 1 - 31336 - 4878
>>> Fax: +43 - 1 - 31336 - 746
>>> Email: stefan.sobernig at wu-wien.ac.at
>>> <mailto:stefan.sobernig at wu-wien.ac.at>
>>> PubKey: http://julia.wu-wien.ac.at/~ssoberni/0x5FC2D3FA.asc
>>> <http://julia.wu-wien.ac.at/%7Essoberni/0x5FC2D3FA.asc>
>>>
>>>
>>>
>>
>
>
> --
>
> Stefan Sobernig
> Department of Information Systems and New Media
> Vienna University of Economics
> Augasse 2-6
> A - 1090 Vienna
>
> Phone: +43 - 1 - 31336 - 4878
> Fax: +43 - 1 - 31336 - 746
> Email: stefan.sobernig at wu-wien.ac.at <mailto:stefan.sobernig at wu-wien.ac.at>
> PubKey: http://julia.wu-wien.ac.at/~ssoberni/0x5FC2D3FA.asc <http://julia.wu-wien.ac.at/%7Essoberni/0x5FC2D3FA.asc>
>
>
>
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-help
mailing list