[Rd] R, Wine, and multi-threadedness.

[Hin-Tak Leung]

Prof Brian Ripley wrote:
> On Thu, 13 Oct 2005, Hin-Tak Leung wrote:
> 
>> I managed to install Win32 R 2.2.0 with the CRAN Innosetup
>> installer under Wine on x86 linux a few days ago. However, on trying
>> to run it, MSVCP60.DLL is missing. So here is a sort of a bug
>> report, and a couple of questions:
> 
> 
> This is a sort of bug report on your report.  The rw-FAQ makes clear 
> that DLL is _only_ required by R if you select East Asian support, and 
> that is not the default.  It seems you chose a non-default option.  
> Please go back and reinstall R without East Asian support.

Sorry - indeed you are right. In my last attempt, I (blindly) selected
every optional packages, and that includes East Asian support.

R does work under wine if that option is not selected.

However, that option is mixed in with other harmless options which 
obviously have no extra requirements (pdf docs, source files, etc) and 
dependencies, and that's somewhat misleading. I would suggest putting it
on a separate screen (and an warning?) in the installer?

I don't think I was particularly careless wanting to install every 
optional part - even without understanding the full implication of
doing so.

>> (1) I think the R binary in the CRAN Innosetup installer was built with
>> mingw. The R-windows FAQ did mention that this DLL is required *for
>> Chinese/Japanese/Korean* (which I wasn't trying to do). In this
>> circumstance, it isn't particularly legal to copy the dll from
>> elsewhere. So I would suggest enhancing R-windows FAQ and even the main
>> R FAQ for this...
> 
> 
> For what?  As far as we know the rw-FAQ is accurate about all the 
> dependencies.

This information can go into the main FAQ (under linux/wine).
Part of the interests (besides the "multi-threadedness") is the GUI
alternatives, which is a bit lacking on the unix front.

> (Note that all current and recently obselete versions of Windows do have 
> it, so its absence is a problem of Wine, not for Windows users of R.)

I did a search on Google, and this DLL is apparently not on win98
as shipped.

>> also, is it possible *not* to have this dependency,
>> or have it runtime-determined (i.e. try to load the dll dynamically,
>> and fall back to US/ascii only when unsuccessful)?
> 
> 
> The MinGW project assumes a tolerably recent version of Windows (from 
> 2000 or later).

That's quite incorrect. Mingw makes little assumption in that regard.
The dependency on that DLL among Mingw people seems to be
quite well-known, but somewhat restricted to wide-char support.

> It would be tricky to have MSVCP60.dll loaded and linked on demand, but 
> not impossible (and it was considered not to be a worthwile use of the 
> core group's time).  We look forwards to your contributing code to do so 
> if you think it is worthwhile.

The circumstance is somewhat more arguable in the other possibility of 
building a win32 executable, via a cross-compiler. There are also
less proprietary alternatives, such as libiconv?

>> (2) The interesting question: As I understand it (could be wrong),
>> R Win32 is (partly) multi-threaded, and the native linux R is not.
>> Is is possible to have better performance or CPU utilisation
>> on multi-CPU systems running Win32 R under Wine rather than natively?
>> At least on certain specific application areas?
> 
> 
> Rterm.exe is multithreaded, but the second thread is only used for 
> input. RGui.exe is singlethreaded.  As R for Windows uses a DLL it is 
> about the same speed (running Windows natively on the same hardware) as 
> R under ix86 Linux using a shared library, and that is appreciably 
> slower than R under ix86 Linux without (see the R-admin manual).  R 
> under Linux can make use of a multithreaded BLAS, but I know of none 
> available for Windows.

Is the Intel MKL not available form Windows? Somewhat surprising...

Hin-Tak Leung