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
[EMAIL PROTECTED]
617-253-3436
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Brian D. Ripley, [EMAIL PROTECTED]
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
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
