[Rd] SurviveGotoBLAS2 for Win64 (human sacrifice release)

[Ei-ji Nakama]

Hi,

2010/12/5 Prof Brian Ripley <ripley at stats.ox.ac.uk>:
> However, like most BLAS this is tied to a particular chip (you don't say what you
> used: my machine is identified as penryn) and I am undecided if it is worth
> provided a range of pre-compiled GotoBLAS2 Rblas.dll (or how wide the range
> would need to be to be useful).

It is the build with DYNAMIC_ARCH.

>  Maybe just "core2" would be useful: maybe penryn, dunnington, nehalem
> and atom are needed.  (A quick look suggests dunnington is not used,
> and nehalem is only used on x86_64.)

If CPU is not identified, an appropriate routine is not used.
However, neither the model of CPU nor the value of the exmodel etc
completely have the rule.
The stack alignments of Win64 are 8bytes in default.
However, stack alignments of Win32 is 4bytes (mingw,thread and DLL case).
Therefore, it doesn't run.
If the results of a lot of CPUID(http://www.etallen.com/cpuid.html)
are collected,
the automatic recognition is ameliorable.

$ ./cpuid | sed -n '/^CPU 0:/,/^CPU 1:/p'|grep "vendor_id" -B0 -C8
  vendor_id = "GenuineIntel"
  version information (1/eax):
     processor type  = primary processor (0)
     family          = Intel Pentium Pro/II/III/Celeron/Core/Core
2/Atom, AMD Athlon/Duron, Cyrix M2, VIA C3 (6)
     model           = 0xc (12)
     stepping id     = 0x2 (2)
     extended family = 0x0 (0)
     extended model  = 0x2 (2)
     (simple synth)  = Intel Core i7-900 (Gulftown B1) / Core i7-980X
(Gulftown B1) / Xeon Processor 3600 (Westmere-EP B1) / Xeon Processor
5600 (Westmere-EP B1), 32nm

> So I'd identified this as something which would need quite a bit of thought,
> maybe something to be done for R 2.13.0.

I reaction may be dull.
-- 
EI-JI Nakama  <nakama (a) ki.rim.or.jp>
"\u4e2d\u9593\u6804\u6cbb"  <nakama (a) ki.rim.or.jp>