From p.dalgaard at biostat.ku.dk  Thu Jun 16 13:51:06 2005
From: p.dalgaard at biostat.ku.dk (Peter Dalgaard)
Date: 16 Jun 2005 13:51:06 +0200
Subject: [Rd] R 2.1.1 slated for June 20
In-Reply-To: <1118918509.3651.26.camel@seurat>
References: <x264wmbe6m.fsf@turmalin.kubism.ku.dk>
	<Pine.LNX.4.61.0506101407430.4262@gannet.stats>
	<1118773739.3126.4.camel@localhost.localdomain>
	<x2d5qoa9nf.fsf@turmalin.kubism.ku.dk>
	<1118786837.3968.14.camel@localhost.localdomain>
	<1118918509.3651.26.camel@seurat>
Message-ID: <x2zmtqo6z9.fsf@turmalin.kubism.ku.dk>

Martyn Plummer <plummer at iarc.fr> writes:

> On Tue, 2005-06-14 at 17:07 -0500, Marc Schwartz wrote:
> > On Tue, 2005-06-14 at 23:52 +0200, Peter Dalgaard wrote:
> > > Marc Schwartz <MSchwartz at mn.rr.com> writes:
> > > 
> > > > On Fri, 2005-06-10 at 14:57 +0100, Prof Brian Ripley wrote:
> > > > > On Fri, 10 Jun 2005, Peter Dalgaard wrote:
> > > > > 
> > > > > > The next version of R will be released (barring force majeure) on June
> > > > > > 20th, with beta versions available starting Monday.
> > > > > >
> > > > > > Please do check them on your system *before* the release this time...
> > > > > 
> > > > > Some things which it would be particularly helpful to have tested:
> > > > 
> > > > 
> > > > > - Bleeding-edge OSes, e.g. anyone running Fedora Core 4 test 3?  (These
> > > > >    often show up problems with bugs in the pre-release versions of
> > > > >    components such as X11 and compilers.)
> > > > 
> > > > 
> > > > Just as a quick heads up, I installed FC4 Release ("Stentz") late
> > > > yesterday.
> > > > 
> > > > R (Version 2.1.1 beta (2005-06-14)) compiles fine using:
> > > > 
> > > > $ gcc --version
> > > > gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
> > > > 
> > > > and make check-all passes with no problems.
> > > > 
> > > > I have also installed all CRAN packages that do not require other 3rd
> > > > party drivers, etc. and there were no observed errors in those cases.
> > > > 
> > > > So far, so good.
> > > > 
> > > > If anything comes up, I will post a follow up.
> > > > 
> > > > Best regards,
> > > > 
> > > > Marc Schwartz
> > > 
> > > Yep. Just tried the same on AMD64 (I had a bit of a fight converting
> > > my SuSE setup -- FC4 is quite unhappy about ReiserFS for some reason).
> > > A couple of f95 warnings whooshed by during the compile, that was all.
> > > 
> > > By the way, I noticed that you can now "yum install R R-devel" and get
> > > everything straight from Fedora Extras.
> > 
> > Yep. Tom "Spot" Callaway is the FE maintainer for R.
> 
> I had a look at his RPM last night.  It includes a patch for gcc4, which
> fails to build R with the fairly aggressive optimizations used by
> rpmbuild. ("-O2 -D_FORTIFY_SOURCE=2" will reproduce the bug, IIRC, but
> I'm not upgrading my work PC just yet, so I can't be sure).  I folded
> this into R-patched.  It's a shame he didn't send a bug report or, if he
> did, I missed it.

Thanks for looking into this. Do you know what is the time frame for
getting a new version into FC-E? Do we actually need separate CRAN
versions any more? BTW, I noticed that the Fedora RPMs depend on a
blas RPM. Do you have any inkling about what that implies? (I've never
quite understood whether there is a "right" way to use a machine
specific BLAS in concert with a packaging system).
 
> I also note he is using the patch that sets LANG=C, which is obsolete
> now that R supports utf-8 locales.  I'll write to him (cc Marc) to let
> him know about these changes.
> 
> The RedHat RPMS also use the shared library version of R.  I've been
> thinking about making this change myself, despite the substantial speed
> penalty, since I've seen a growing number of people recompiling to get
> the shared library.  The Red Hat choice forces my hand though: I don't
> want people upgrading from their R 2.1.0 to my R 2.1.1 and finding their
> installed packages don't work anymore.  The $64,000 question is how many
> people are going to care about that 15-20% decrease in speed. Speak up
> now if it concerns you.

What is a good way to measure that? For hardcore numerics, it is
certainly much less than 15% on the AMD64:

# RPM:
> system.time(solve(matrix(rnorm(1e6),1e3)))
[1] 8.64 0.15 8.86 0.00 0.00

# My private build
[pd at localhost ~]$ r-patched/BUILD/bin/R -q
> system.time(solve(matrix(rnorm(1e6),1e3)))
[1] 8.49 0.15 8.64 0.00 0.00

(and there is a substantial replication variation on those numbers). 

For more integer-bound stuff like

system.time(p <- replicate(10000,t.test(rexp(25),mu=1)$p.value))

I get about 14.1s with the RPM and 11.7s with my build.
 

-- 
   O__  ---- Peter Dalgaard             ?ster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph: (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907



[Rd] R 2.1.1 slated for June 20
Peter Dalgaard