Skip to content

Problems building R 2.2.1 with libgoto and SSE2 enabled

3 messages · Ivan Adzhubey, Brian Ripley, Peter Dalgaard

Ivan Adzhubey
# 
Hi,

I am trying to build R 2.2.1 with Kazushige Goto's BLAS library (libgoto) and 
encountered a problem: I have two computers with the almost identical 
hardware (P4 Northwood CPU, i875 chipset, 2GB DDR400 RAM) and identical Linux 
OS. I have the latest version of libgoto for this CPU installed on both boxes 
(libgoto_northwood32p-r1.00.so) and I am using gcc compiler flags "-O2 
-march=pentium4 -mfpmath=sse -msse2" to enable use of SSE2 extensions. With 
one computer that works perfectly, while on the other one "make check" 
constantly fails on lm-test. If I remove "-mfpmath=sse -msse2" part from the 
gcc flags then all checks pass on the second computer too. Any hints on what 
may cause the error? Anyone willing to share his/her experience on building 
and using R with SSE2 and on libgoto performance in particular? I was 
planning to give ATLAS a try but pre-built binaries are not available for my 
distro and on my AMD Opteron cluster it took almost 48 hours to build. I am 
not sure my home computer (the one that gives me errors with libgoto/SSE2) 
would survive this.

TIA,
Ivan
Brian Ripley
# 
[This sort of highly technical non-R issue would be better discussed on 
the R-devel list.  See the R posting guide.]

Do note the comments in the R-admin manual.  R requires proper results 
with IEEE754 specials (Infs and NaNs) and switching on fast arithmetic 
options often calls failures because of this.  It is not clear from your 
description what compiler you are using (presumably some version of gcc), 
and how it handles this.  Since gcc's AMD64 code makes use of such 
extensions it may be safe, but we don't know about your compiler/CPU 
combination.   Generally the advice is that it takes more time to 
investigate wrong results from over-optimization (as now, and it is not 
just your time in this case) than to make use of safer options.

However, without knowing what the failure is (look in the 
tests/foo.Rout.fail file) we can only speculate.

Building ATLAS should take only a couple of hours at most for platforms 
where there are good defaults, and that includes P4 on Linux.  I had a lot 
of problems on Opteron, basically because my machine was too fast for the 
timing loops (and you also need to ensure that PIC code is used).
On Thu, 23 Feb 2006, Ivan Adzhubey wrote:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Peter Dalgaard
    

    

      
      #
    

  


  

      
Ivan Adzhubey <iadzhubey at rics.bwh.harvard.edu> writes:

            

      
      
      
    

        
Some hints, nothing conclusive:

Different gcc versions? glibc? (perhaps only one machine was updated).

Does libgoto factor into this at all? Will things still (not) work if
you omit it? If so, are you sure that both machines are picking it up
correctly?

Which test is failing?

            

      
      
      
    

        
Build times for ATLAS are highly dependent on platform. On P4, it is
usually quite fast (since most choices are known in advance). 11
*minutes* on the one I'm using to type this. 

(Why are you keeping your Linux distro a secret, BTW?)