[Rd] 32 vs 64 bit difference?

[Terry Therneau]

Thank you both for the nice explanation.  I added "digits=4" to my
print statements to shorten the display.  
 Mixed effects Cox models can have difficult numerical issues, as it
turns out; I've added this to my collection of things to watch for.

Terry Therneau



On Sat, 2011-11-26 at 11:37 +0000, Prof Brian Ripley wrote:
> On 26/11/2011 09:23, peter dalgaard wrote:
> >
> > 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.
> 
> However, the main difference is that all x86_64 chips have SSE2 
> registers, and so gcc makes use of them.  Not all i686 chips do, so 
> 32-bit builds on Linux and Windows only use the FPU registers.
> 
> This matters at ABI level: arguments get passed and values returned in 
> SSE registers: so we can't decide to only support later i686 cpus and 
> make use of SSE2 without re-compiling all the system libraries (but a 
> Linux distributor could).
> 
> And the FPU registers are 80-bit and use extended precision (the way we 
> set up Windows and on every Linux system I have seen): the SSE* 
> registers are 2x64-bit.
> 
> I believe that all Intel Macs are 'Core' or later and so do have SSE2, 
> although I don't know how much Apple relies on that.
> 
> (The reason I know that this is the 'main difference' is that you can 
> often turn off the use of SSE2 on x86_64 and reproduce the i686 results. 
>   But because of the ABI differences, you may get crashes: in R this 
> matters most often for complex numbers which are 128-bit C99 double 
> complex and passed around in an SSE register.)
> 
> >>
> >> Terry Therneau
> >>
> >> ______________________________________________
> >> R-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
>