[R-SIG-Mac] How to make Mac 64-bit version feature complete?

[Simon Urbanek]

On Dec 14, 2011, at 3:42 PM, Adam Strzelecki wrote:

> I guess this discussion is going nowhere. Since I am always wrong I give up.
> 

I would consider understanding/learning a more productive approach than surrender, but it's up to you ;).

From the beginning you were confusing several entirely unrelated topics (plus unrelated subject), so I'll try for the last time to make it more clear and separate them properly and address them again:

a) 3-way fat R.app (your proposal) vs 2-way fat R.app + 1-way R64.app (CRAN release).
This is entirely a choice of convention and we have decided to separate 32-bit binaries from the 64-bit binary for convenience of the user. As I said there are several reason for this. Whether you like it or not is quite irrelevant - it may not be what Safari does but then Safari is not a stat computing language. Whether you use lipo to add the 64-bit binary to R.app or not is purely cosmetic, it doesn't change the fundamental functionality (except that with R.app+R64.app you can run them in parallel and start the desired architecture more easily - and the user knows what he gets and doesn't need to guess - less relevant for Safari, more so for R).


b) multi-lib approach in R itself: (for packages, modules etc.). This is deliberate and I was illustrating that it is very common even in OS X as you can see in the gcc example. The main reason is portability because this way the build system needs to be implemented only once for all platforms. This is hidden from the user so you should not care. If you do, you may need to read up on it.


c) decision to run 32-bit vs 64-bit binaries. This we leave entirely to the user. You may not be familiar with the details (the link you quoted below is quite irrelevant in the sense that the biggest waste of memory is not on the stack - unless you use deep recursion), but each of the architectures has its weaknesses and advantages. For low-memory machines it is often advisable to use 32-bit binary as the benefits of the 64-bit instruction set are really not that big (and the numerical stability is different, some would say worse). 64-bit binary *always* uses more memory, by definition, that's not even a question. The question is only how much more, and in some practical settings it can be close to 100% more. But, again, we leave this to the user.


d) "How to make Mac 64-bit version feature complete?" Well, the CRAN 64-bit version of R *is* feature complete so the question goes off an invalid assumption. Later you mentioned rgl, but that is not part of R.



> I say having both R.app, R64.app is doubtful (talking about apps from users perspective), you justify that with dumps of some GCC directories from Xcode developer tools (talking about developer tools directories from developer perspective). Can you find me single other app for Mac that comes as two .app packages for each architecture from one install?
> 
> I say installing R in 64-bit Linux and launching R GUI app

There is no such thing on Linux. R.app exists only on OS X. Windows has Rgui and it has two of them as well (32-bit and 64-bit) and they also come with two separate icons, same as on OS X. Go figure :).


> launches 64-bit version (talking how Linux hides its internals), you say I am wrong because you can launch 32-bit app using --arch param. Yes you can, does it prove it is wrong what I said? Typing "R" in OSX command line also launches R in 64-bit, why not 32-bit then?
> 

Because this decision is made at install time depending on your OS X version - it is 32-bit for Leopard, for example. Whether this is the right thing to do is up for discussion (when installed from source you'll get the last installed architecture). R.app doesn't need to make that decision, since it is always 32-bit - easy.

I hope that helps understanding it a bit better. If not, please, consider learning more about R.

Cheers,
Simon


> I say 64-bit code is faster (haven't used "always", but intentionally used word "code" not "program" or "libraries", because these can be badly ported to 64-bit due old compiler or 32-bit only hand optimized assembly code not working for 64-bits, I refer to the machine code that has more wider registers than in 32-bit mode), you say it is not; because it can be slower of faster depending on task, huh :/
> 

Yep. If you know a bit more about CPUs, you'll realize that we width of the register is quite irrelevant until you actually use it - which is not very often the case (there are very few actual 64-bit operations). The most time you use it is with pointers where you would have used 32-bit on x86 anyway so you don't gain anything, rather to the contrary. You can gain from having more registers, but only for functions with larger number of arguments (register passing) or functions that are complex enough (fn body). Also larger objects (due to double the size of pointers) mean more very slow operations (out-of-cache memory I/O) and thus slower performance. Most gains you see are in fact due to something different - the fact that x86_64 CPUs can be assumed to have extensions that some old x86 CPUs did not have (various SIMD instructions etc.) which can be used instead of the FPU.

Even if you don't know much about Intel CPU architecture, just run some benchmarks in R - you'll see that it goes either way - you'll have tasks that are slower in 64-bit and you'll have other tasks that are faster in 64-bit (you may be able to dig up examples from this list). It really depends on things like the memory I/O load + data size, types of vectors you operate on, proportion of interpreted code etc. Since R is an interpreter, you'll see bigger negative impact due to increased 64-bit pointer size than you would see in native code (the most vulnerable are generic vectors, lists, environments and character vectors - which are incidentally the most used objects).


> You say 64-bit code always use more memory, then you've probably read that: http://software.intel.com/en-us/blogs/2010/07/01/the-reasons-why-64-bit-programs-require-more-stack-memory/
> 
> Altogether I am just plain wrong :)
> 
> Thank you,
> -- 
> Adam Strzelecki
>