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

[Olivier Delalleau]

The blas implementation you are using may be slow. Here's my ldd on
_dotblas.so, that shows it is using libblas (this is on Ubuntu 11.04):

        linux-vdso.so.1 =>  (0x00007fffad5ff000)
        libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007fc608ea4000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.
6 (0x00007fc608b10000)
        libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3
(0x00007fc60882b000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc6085a6000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007fc608390000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc609352000)

My guess is BLAS is implemented in libsunmath.so but is a slow
implementation. It's really just a guess though...

-=- Olivier

2011/9/20 David Cottrell <david.cottrell at gmail.com>

> 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
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110920/8c0032d0/attachment.html>