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.cottr...@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 <sc...@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@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@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion