[Numpy-discussion] numpy blas running slow: how to check that it is properly linked

David Cottrell david.cottrell at gmail.com
Tue Sep 20 09:56:24 EDT 2011


Thanks, just getting back to this. I just checked again, and after
setting my LD_LIBRARY_PATH properly, ldd shows _dotblas.so pointing
and the sunmath and sunperf libraries. However the test_03.py still
runs at about 8-9 seconds ... far too slow.

~/local/lib/python3.1/site-packages/numpy/core $ ldd _dotblas.so | sed
-e 's/$me/$USERNAME/g'
        libsunperf.so.8 =>
/home/$USERNAME/local/archive/SolarisStudio12.2-solaris-sparc-tar-ML/solstudio12.2/lib//libsunperf.so.8
        libsunmath.so.1 =>
/home/$USERNAME/local/archive/SolarisStudio12.2-solaris-sparc-tar-ML/solstudio12.2/lib//libsunmath.so.1
        libgcc_s.so.1 =>         /usr/sfw/lib/libgcc_s.so.1
        libfsu.so.1 =>
/home/$USERNAME/local/archive/SolarisStudio12.2-solaris-sparc-tar-ML/solstudio12.2/lib//libfsu.so.1
        libfui.so.2 =>
/home/$USERNAME/local/archive/SolarisStudio12.2-solaris-sparc-tar-ML/solstudio12.2/lib//libfui.so.2
        libpicl.so.1 =>  /usr/lib/libpicl.so.1
        libmtsk.so.1 =>  /lib/libmtsk.so.1
        libm.so.2 =>     /lib/libm.so.2
        libc.so.1 =>     /lib/libc.so.1
        libm.so.1 =>     /lib/libm.so.1
        libdl.so.1 =>    /lib/libdl.so.1
        libdoor.so.1 =>  /lib/libdoor.so.1
        libthread.so.1 =>        /lib/libthread.so.1
        libkstat.so.1 =>         /lib/libkstat.so.1
        libpthread.so.1 =>       /lib/libpthread.so.1
        librt.so.1 =>    /lib/librt.so.1
        libaio.so.1 =>   /lib/libaio.so.1
        libmd.so.1 =>    /lib/libmd.so.1
        /platform/SUNW,Sun-Fire-V490/lib/libc_psr.so.1
        /platform/SUNW,Sun-Fire-V490/lib/libmd_psr.so.1

~/local/lib/python3.1/site-packages/numpy/core $ ~/python/numpy/B/test_03.py
No ATLAS:
8.49377894402
(1000, 1000) (1000,) (1000, 1000)


On Wed, Sep 7, 2011 at 9:08 AM, Samuel John <scipy at samueljohn.de> wrote:
>
> On 06.09.2011, at 22:13, David Cottrell wrote:
>
>> Thanks, I didn't realize dot was not just calling dgemm or some
>> variant which I assume would be reasonably fast. I see dgemm appears
>> in the numpy code in various places such as the lapack_lite module.
>>
>> I ran the svd test on the solaris setup and will check the OSX run
>> when back at my laptop. 8.4 seconds is slightly slower than matlab but
>> still seems reasonable.
>>
>> $ ./test_03.py
>> No ATLAS:
>> (1000, 1000) (1000,) (1000, 1000)
>> 8.17235898972
>
> I just ran your benchmark code on OSX 10.7.1 on an 2011 MacBook Pro (core-i7) with numpy.version.version '2.0.0.dev-900d82e':
>   Using ATLAS:
>   ((1000, 1000), (1000,), (1000, 1000))
>   0.908223152161
>
> cheers,
>  Samuel
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
David Cottrell
+1 416 995 9860
http://ca.linkedin.com/in/dcottrell



More information about the NumPy-Discussion mailing list