Re: nVidia Optumus prevents using CUDA?
- To: mathgroup at smc.vnet.net
- Subject: [mg122745] Re: nVidia Optumus prevents using CUDA?
- From: "Oleksandr Rasputinov" <oleksandr_rasputinov at hmamail.com>
- Date: Tue, 8 Nov 2011 07:17:42 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- References: <201111041102.GAA29243@smc.vnet.net> <j98dle$3re$1@smc.vnet.net>
On Mon, 07 Nov 2011 10:58:54 -0000, Oliver Ruebenkoenig
<ruebenko at wolfram.com> wrote:
> On Fri, 4 Nov 2011, Oleksandr Rasputinov wrote:
>
>> On Thu, 03 Nov 2011 08:44:37 -0000, Oliver Ruebenkoenig
>> <ruebenko at wolfram.com> wrote:
>>
>>>> As you see, this does not involve Visual Studio Express, which I
>>>> deliberately avoided since it does not include the 64-bit compilers
>>>> necessary for operation with Mathematica. Personally, I use MinGW-w64
>>>> GCC
>>>> 4.6.1 rather than Visual C++; this works perfectly well also but does
>>>> require modifications to Mathematica which I will not discuss here
>>>> other
>>>> than to say that it would be nice if this compiler could be supported
>>>> without need of modifications in a future release.
>>>>
>>>>
>>>
>>> I filed this as a suggestion for a future version.
>>>
>>> Oliver
>>>
>>
>> Many thanks. For reference, this support is not very difficult to
>> implement: apart from some (trivial) changes to
>> CCompilerDriver/MinGWCompiler.m and
>> CCompilerDriver/CCompilerDriverRegistry.m, the only other prerequisite
>> is
>> to have the necessary libraries (ml32i3m.lib/ml64i3m.lib etc.) provided
>> in
>> GNU COFF format in addition to the ones in MS COFF format. Import
>> libraries can be generated automatically from the associated DLLs (using
>> MinGW gendef followed by dlltool), and static link libraries can be
>> converted automatically as well (using MinGW ranlib). One thing to note
>> is
>> that MinGW-w64 is a multilib build--i.e. it can produce both 32- and
>> 64-bit binaries--so you need to provide GNU COFF versions of both sets
>> of
>> libraries.
>>
>> The only problem I ran into in implementing the support myself was that
>> ml32i3s.lib and ml64i3s.lib are linked against the static version of the
>> MS C runtime (libcmt.lib), which means they cannot successfully be
>> converted automatically due to certain dependencies. Fixing this is
>> possible but would be a lot easier if they were instead linked against
>> the
>> dynamic C runtime (msvcrt.dll/msvcr80.dll etc.) instead--however, I
>> didn't
>> actually try as I couldn't think of any reason why one would want to
>> build
>> a statically-linked MathLink program in the first place, so for me these
>> libraries are superfluous anyway.
>>
>
> I am anything else but an expert on this, so I asked around a little.
> The following is about MinGW-64w. The problem here is that the DLL C
> run-time lib does not ship with Windows. So it needs to be installed
> additionally, possibly requiring admin privileges. Also, the the DLL c
> run-time lib changes from Visual Studio version to version. It looks
> unlikely this is going to be part of Mathematica.
>
> Oliver
>
Many thanks for making inquiries on my behalf. However, the responses you
received do appear to reflect some misconceptions that I would like to
clear up.
MinGW-w64 builds against msvcrt.dll, not (like Visual C++) against
msvcr{70,71,80,90,100}.dll. This is mainly for the reasons you state, as
well as because using the newer runtimes requires the generation and
inclusion in the executable of an XML manifest, which is inconvenient. In
contrast to the newer libraries, msvcrt.dll implements relatively fixed
functionality (i.e. it doesn't change much from version to version), and
it is included in every copy of Windows. (Because of this, all Windows
drivers are built against msvcrt.dll, by means of some extra files which
are contained in the Windows Driver Kit
(http://www.microsoft.com/download/en/details.aspx?id=11800) but for some
reason not included in Visual Studio. These files (msvcrt_winxp.obj, etc.)
make up the difference between the msvcrt.dll available on the chosen
platform and the current version of msvcr*.dll as of the time of release
of the WDK.)
If it were the case that compilers compatible with Mathematica must be
able to build against whatever version of msvcr*.dll was used to build
that version of Mathematica, this would be an argument against supporting
other versions of Visual C++, the Intel C compiler, as well as (on 32-bit
platforms only) Cygwin GCC and MinGW (i.e. non-w64) GCC. However, these
compilers are supported. In fact, the only important difference is that
these other compilers can link against MS-COFF format libraries, whereas
MinGW-w64 requires GNU COFF format. Fortunately, the format conversion can
be achieved automatically using tools that form part of MinGW, so
supporting MinGW-w64 ends up being very straightforward.
To the extent that you (i.e. the developers of Mathematica) would be
prepared to build the static MathLink libraries against msvcrt.dll using
the WDK or files from it, this would allow for automatic conversion of
ml{32,64}i3s.lib to GNU COFF format as well. However, as mentioned above,
it seems to me that the static versions of the MathLink libraries are of
little use anyway, so this extra effort is by no means necessary to
support MinGW-w64. (I think I am right in saying that ml{32,64}i3s.lib as
supplied actually will not work with any of even the officially supported
compilers except Visual C++ 2005 for the same reasons, but nobody seems to
have noticed so far. We can probably take this as indicative.)
Given that adding support for MinGW-w64 relatively trivial, it wouldn't be
a great loss to me personally if it was never officially supported.
However, MinGW-w64 gfortran is one of very few good free Fortran compilers
for 64-bit Windows, and supporting MinGW-w64 GCC for compilation of
Wolfram Libraries would greatly simplify linking Mathematica with Fortran
codes, while patching the CCompilerDriver` package in order to achieve
this isn't for everyone. Hopefully this will provide sufficient motivation
to consider official support.
Best,
O. R.
- References:
- Re: nVidia Optumus prevents using CUDA?
- From: "Oleksandr Rasputinov" <oleksandr_rasputinov@hmamail.com>
- Re: nVidia Optumus prevents using CUDA?