MathGroup Archive 2011

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: nVidia Optumus prevents using CUDA?

On Mon, 07 Nov 2011 10:58:54 -0000, Oliver Ruebenkoenig  
<ruebenko at> wrote:

> On Fri, 4 Nov 2011, Oleksandr Rasputinov wrote:
>> On Thu, 03 Nov 2011 08:44:37 -0000, Oliver Ruebenkoenig
>> <ruebenko at> 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  
( 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.


O. R.

  • Prev by Date: Re: How to evaluate parts of an expression, but not other parts?
  • Next by Date: Re: How to eliminate noises? A better way perhaps.
  • Previous by thread: Re: nVidia Optumus prevents using CUDA?
  • Next by thread: Re: nVidia Optumus prevents using CUDA?