[R-SIG-Mac] 2.7.0 for 64-bit running Leopard

[Simon Urbanek]

I fully agree with Brian on the points he made, just one technical  
detail inline:

On May 8, 2008, at 1:24 AM, Prof Brian Ripley wrote:
> I think you need to distinguish a release of R (which is a source  
> tarball) from a binary redistribution.  The sources are set up to  
> allow you to build x86_64 on MacOS, and also multiple architectures  
> (and have been for some time if you don't want MacOS-specific  
> features such as quartz() -- that came in 2.7.0).
>
> On Wed, 7 May 2008, Michael Braun wrote:
>
>> Is it possible to get some clarification regarding what is  
>> considered a "release" configuration of R and what is considered  
>> "experimental?"  I would like to run a 64-bit build of R 2.7.0 on  
>> an x86_64 Mac Pro with 18GB of RAM running Leopard (10.5.2).  When  
>> I install the precompiled "universal" binary,
>
> According to the FAQ 2.5, 'universal' means Intel and PowerPC.  The  
> package instructions in 5.4 are for i386 and ppc.
>
>> it appears that I am getting a 32-bit build (I think this because I  
>> cannot allocate objects of size >3GB and because .Platform 
>> $r_arch="i386").
>
> The real test is .Machine$sizeof.pointer .  'r_arch' is just a label.
>
>> I checked out the r.research.att.com site, but I am hesitant to  
>> install an "experimental" build.  Also, I tried compiling R myself,  
>> but ran into a large number of issues (including not passing make  
>> check, which I now see is addressed in the FAQ).
>
>> So my question is, once 10.5.3 is released, should the binary I  
>> download from CRAN install a 64-bit version of R?  Will I need to  
>> compile from source?  Or am I still too far ahead of the curve?
>
> I suggest you do compile from sources.  I find Apple's compilers  
> flaky and that is the issue.  Despite the comment in the FAQ, I've  
> had no problems with x86_64 on MacOS 10.5.2 *if I turn optimization  
> off* .  The issue with log10 appears to be on-CPU calls and not  
> calls to the log10 in libm.


I have to disagree on this point:

ginaz:sandbox$ gcc -m64 l10.c -o l10 -O0 && ./l10
log10(100)=0.000000, log10(10)=1.000000, log10(15)=0.000000

I get the same (incorrect result) regardless of compiler and  
optimization. Allegedly the problem is an ABI mismatch:
http://lists.apple.com/archives/scitech/2008/Mar/msg00032.html
In some code it may accidentally work if the register happened to load  
the same value in previous computations.

Best,
Simon

(PS: Sorry for the late reply, I had a work-around on my machine as  
well as beta compilers, so I had to test it on various other machines  
to make sure it is the "real" behavior. Reportedly only OS X 10.5.2  
libSystem is affected)

l10.c: int main() { printf("log10(100)=%f, log10(10)=%f, log10(15)=%f 
\n", log10(100), log10(10), log10(15)); return 0; }


>
> (OTOH, since I get higher performance from x86_64 Linux and Solaris  
> boxes, I haven't done extensive testing.)  Note that this may not be  
> the only such issue: gcc 4.3.x has a similar problem with sqrt on  
> x86_64 when optimizing.
> You'll need to compile everything from sources (including all  
> packages), and it does sometimes help to have the same compilers  
> used throughout.
>
>
>> Thanks,
>>
>> Michael
>>
>>
>>
>>
>>
>>
>> Michael Braun
>> Assistant Professor of Management Science (Marketing Group)
>> MIT Sloan School of Management
>> One Amherst St., E40-169
>> Cambridge, MA 02142
>> braunm at mit.edu
>> 617-253-3436
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
> -- 
> 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
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
>