[SciPy-user] matrix inversion time (Python vs MATLAB)

David Cournapeau david@ar.media.kyoto-u.ac...
Sun Jan 11 03:42:13 CST 2009


David Cournapeau wrote:
> On Sun, Jan 11, 2009 at 8:42 AM,  <josef.pktd@gmail.com> wrote:
>   
>> On Sat, Jan 10, 2009 at 6:08 PM, Matthieu Brucher
>> <matthieu.brucher@gmail.com> wrote:
>>     
>>>> So I think that, if you want to link against mkl, then the best would
>>>> be to make a local copy of the dlls. This seems to be the common
>>>> policy,  for example, I have more than 10 programs (mostly open
>>>> source, including numpy/scipy) that all have their own lapack in the
>>>> local directories.
>>>>         
>>> Contrary to usual programs, Python is scattered in several folders,
>>> and in the absolute, the dll should be put in the main Python folder
>>> to be seen by Python at runtime. But then what would you do if other
>>> modules provide their own MKL dlls?
>>>       
>> Currently scipy has duplicates of lapack, blas in different folders,
>>     
>
> Not really: we have copy of blas/lapack in scipy/lib, but that has
> nothing to do with build issues: the code itself is duplicated.
>
>   
>> so having several copies
>> of another set of dlls wouldn't make much difference.
>>     
>
> Sure, but then you have to wonder: what's the point of dynamic linking
> :) Statically linking everything is more or less the same as copying
> the dll everywhere, with the benefit it is more reliable. The drawback
> is memory waste (since the code cannot be shared), but well, it is not
> like a few MB will make a difference on windows.
>   

Now that I think about it, I am not even sure that the dll can be shared
anyway if we copy it. After all, they are copied because the dynamic
loader needs them there, and I am not sure the loader will check that
they are the same (Even if the files are exactly the same, maybe two
copies were provided to avoid some sharing - but this is getting far
beyond my knowledge on how this stuff work).

David


More information about the SciPy-user mailing list