I tried reproducing the results from your gist using scipy 0.19.0, and I found that Xmat is aligned after loadmat:

In [3]: Xmat = sio.loadmat('data.mat')['X']

In [4]: Xmat.flags

Out[4]: 

  C_CONTIGUOUS : False

  F_CONTIGUOUS : True

  OWNDATA : False

  WRITEABLE : True

  ALIGNED : True

  UPDATEIFCOPY : False

On Mon, Aug 28, 2017 at 1:26 PM, Robert Kern <robert.kern@gmail.com> wrote:

On Mon, Aug 28, 2017 at 10:13 AM, Jonathan Taylor <jonathan.taylor@stanford.edu> wrote:
>
> Thanks for all the help.
>
> That said, I'm not sure it is an issue of the strides. I can easily recreate the slowdown as in the above gist ( https://gist.github.com/da7b2ef6ef109511af06a9cebbfc8ed1 ). Also, modifying the flags of a user-created ndarray so they agree with the loaded one is still noticably faster than using the array from `scipy.io.loadmat`

Ah yeah, if the data is aligned, then that might end up faster. Your optimized BLAS will be able to use certain CPU instructions that require aligned data. Setting the ALIGNED flag to false won't actually make the data unaligned; your BLAS checks the data itself, not the numpy flag.

> For my purposes, a copy is just fine, but I think this might be an issue that could be looked into. Perhaps I should file an issue on github?

It might be worth checking if scipy.io.loadmat() can be made to ensure that it always creates aligned arrays. There isn't anything to be done about .dot(), though.

--
Robert Kern

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@python.org
https://mail.python.org/mailman/listinfo/scipy-dev

_______________________________________________
SciPy-Dev mailing list
SciPy-Dev@python.org
https://mail.python.org/mailman/listinfo/scipy-dev