I too encourage users to use scipy.linalg for speed and robustness (hence calling this scipy.dot), but it just brings so much confusion! When using the scipy + numpy ecosystem, you'd almost want everything be done with scipy so that you get the best implementation in all cases: scipy.zeros(), scipy.array(), scipy.dot(), scipy.linalg.inv().
Anyway this is indeed for another thread, the confusion we'd like to fix here is that users shouldn't have to understand the C/F contiguous concepts to get the maximum speed for np.dot() To summarize: - The python snippet I posted is still valid and can speed up your code if you can change all your dot() calls. - The change in dotblas.c is a bit more problematic because it's very core. I'm having issues right now to replicate the timings, I've got better timing for a.dot(a.T) than for a.dot(a). There might be a bug. It's a pain to test because I cannot do the test in a single python session. I'm going to try to integrate most of your suggestions, I cannot guarantee I'll have time to do them all though. -nicolas On Fri, Nov 9, 2012 at 8:56 AM, Nathaniel Smith <[email protected]> wrote: > On Fri, Nov 9, 2012 at 4:25 PM, Gael Varoquaux > <[email protected]> wrote: >> On Fri, Nov 09, 2012 at 03:12:42PM +0000, Nathaniel Smith wrote: >>> But what if someone compiles numpy against an optimized blas (mkl, >>> say) and then compiles SciPy against the reference blas? What do you >>> do then!? ;-) >> >> This could happen. But the converse happens very often. What happens is >> that users (eg on shared computing resource) ask for a scientific python >> environment. The administrator than installs the package starting from >> the most basic one, to the most advanced one, thus starting with numpy >> that can very well build without any external blas. When he gets to scipy >> he hits the problem that the build system does not detect properly the >> blas, and he solves that problem. >> >> Also, it used to be that on the major linux distributions, numpy would not >> be build with an optimize lapack because numpy was in the 'base' set of >> packages, but not lapack. On the contrary, scipy being in the 'contrib' >> set, it could depend on lapack. I just checked, and this has been fixed >> in the major distributions (Fedora, Debian, Ubuntu). >> >> Now we can discuss with such problems should not happen, and put the >> blame on the users/administrators, the fact is that they happen often. I >> keep seeing environments in which np.linalg is unreasonnably slow. > > If this is something that's been a problem for you, maybe we should > start another thread on things we could do to fix it directly? Improve > build instructions, advertise build systems that set up the whole > environment (and thus do the right thing), make numpy's setup.py > scream and yell if blas isn't available...? > > -n > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
