[Rd] 32 vs 64 bit difference?

peter dalgaard pdalgd at gmail.com
Sat Nov 26 10:23:42 CET 2011

On Nov 26, 2011, at 05:20 , Terry Therneau wrote:

> I've spent the last few hours baffled by a test suite inconsistency.
> The exact same library code gives slightly different answers on the home 
> and work machines  - found in my R CMD check run.  I've recopied the entire
> directory to make sure it's really identical code. 
>  The data set and fit in question has a pretty flat "top" to the likelihood.
> I put print statements in to the "f()" function called by optim, and the
> two parameters and the likelihood track perfectly for 48 iterations, then
> start to drift ever so slightly:
> < theta= -3.254176 -6.201119 ilik= -16.64806 
>> theta= -3.254176 -6.201118 ilik= -16.64806 
> And at the end of the iteration:
> < theta= -3.207488 -8.583329 ilik= -16.70139 
>> theta= -3.207488 -8.583333 ilik= -16.70139 
> As you can see, they get to the same max, but with just a slightly
> different path.
>  The work machine is running 64 bit Unix (CentOS) and the home one 32 bit
> Ubuntu.
> Could this be enough to cause the difference?  Most of my tests are
> based on all.equal, but I also print out 1 or 2 full solutions; perhaps 
> I'll have to modify that?

We do see quite a lot of that, yes; even running 32 and 64 bit builds on the same machine, an sometimes to the extent that an algorithm diverges on one architecture and diverges on the other (just peek over on R-sig-ME). The comparisons by "make check" on R itself also give off quite a bit of "last decimal chatter" when the architecture is switched. For some reason, OSX builds seem more consistent than Windows and Linux, although I have only anecdotal evidence of that. 

However, the basic point is that compilers don't define the sequence of FPU operations down to the last detail, an internal extended-precision register may or may not be used, the order of terms in a sum may be changed, etc. Since 64 bit code has different performance characteristics from 32 bit code (since you shift more data around for pointers), the FPU instructions may be differently optimized too. 

> Terry Therneau
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com

More information about the R-devel mailing list