[R-SIG-Mac] How to determine if a Mac is Nehalem-based

[Simon Urbanek]

On Oct 22, 2010, at 9:58 AM, Steve Lianoglou wrote:

> Hi,
> 
> Although I should, I don't follow too closely in the places I should
> (I don't know where those places are) to know if Apple is aware of
> this vecLib breakdown issue ... are they? Where can we go to add our
> voices/votes for them to fix it?
> 

The way to go is to file a concise bug report (simply using let's say DGEMM timings) - but I did not have time to do so. If someone else wants to go ahead, let me know and I can pass on the bug # to our contacts at Apple.


> Apple still has their apple.com/science section, so I guess this
> should be (somehow) important to them ... maybe we can make an
> R-SIG-Mac 20-person-strong tidal wave to help force their hand? ;-)
> 

Good question - and it's not only R people that are appalled.

Cheers,
Simon


> 
> 
> On Thu, Oct 21, 2010 at 12:36 PM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> On Oct 21, 2010, at 7:47 AM, Stefan Evert wrote:
>> 
>>> 
>>> On 21 Oct 2010, at 03:28, Simon Urbanek wrote:
>>> 
>>>> It's not vague at all, it's MacPro4,1 and MacPro5,1 models (you can use use "sysctl hw.model" to find out what you have). If in doubt, check on Wikipedia ;)
>>>> 
>>>> The latter uses the Nehalem architecture but I don't have a specimen of those so I can't confirm that the bug still holds true for those.
>>> 
>>> Not just those ... I'm plagued by the same problem on my Penryn-based MacBookPro4,1.  In 64-bit mode, BLAS performance breaks down to single core levels, whereas in 32-bit mode (i.e. R --arch=i386) it uses both cores.  I posted some benchmark results to this list a few weeks ago.
>>> 
>> 
>> Well, given that it is only a two-thread CPU there is not much you can gain so I wouldn't lose my sleep over it. If you have 16-theads CPU it's a while different story ;). For illustration, those are the timings from your benchmarks (only those that use BLAS) for 64-bit R 2.12.0 at 10.6.4 on a 2.66GHz MacPro4,1:
>> 
>> test                    R BLAS  vecLib  ATLAS   MKL
>> inner M %*% t(M) D      19.961  3.470   0.519   0.662
>> inner tcrossprod D      0.658   1.867   0.243   0.235
>> inner crossprod t(M) D  9.574   1.849   0.242   0.256
>> cosine normalised D     0.798   2.009   0.385   0.411
>> cosine general D        0.770   1.993   0.380   0.352
>> euclid() D              2.072   3.271   1.637   1.635
>> euclid() small D        0.515   0.821   0.421   0.395
>> 
>> As you can see both MKL and ATLAS outperform vecLib and R BLAS by an order of magnitude. It's sad, because vecLib used to be fairly well optimized ... (in fact it is actually some version of ATLAS which is even more strange ...).
>> 
>> 
>>> My solution has also been to switch to the reference BLAS, which outperforms vecLib on most of the operations I benchmarked, except for crossprod(), which is terribly slow (more than 10x slower than tcrossprod()).  I've just tested again with R 2.12.0, and the situation has become even worse: now an explicit matrix multiplication M %*% t(M) -- which used to be fast -- performs as poorly as crossprod().
>>> 
>>> Any ideas about this?  The crossprod() slowdown isn't a Mac problem: I got similar results on a Pentium Dual Core laptop running Ubuntu.  If this is a known problem of the reference BLAS, is there any way to work around it?
>>> 
>>> Apart from the speed hiccups, in my benchmarks vecLib BLAS performed consistently slower than the reference BLAS.  Is there evidence from other benchmarks / hardware architectures that vecLib can be faster?  If not, perhaps the default should be _not_ to use vecLib on Mac?  Or perhaps it would be possible to autodetect hardware in the R startup wrapper and select the BLAS that's known to run faster on this setup?
>>> 
>> 
>> I don't think we would want to do that since that would prevent the user from choosing the BLAS they want to use. We will probably abandon vecLib as the default for the next release (more due to its numerical instability issues) and maybe provide all three options (vecLib, R BLAS, ATLAS) for the user to choose from in case they have a machine that can take advantage of it.
>> 
>> Cheers,
>> Simon
>> 
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
> 
> 
> 
> -- 
> Steve Lianoglou
> Graduate Student: Computational Systems Biology
>  | Memorial Sloan-Kettering Cancer Center
>  | Weill Medical College of Cornell University
> Contact Info: http://cbio.mskcc.org/~lianos/contact
> 
>