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` 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? On Sat, Aug 26, 2017 at 11:06 AM, Robert Kern <robert.kern@gmail.com> wrote:
On Sat, Aug 26, 2017 at 12:09 AM, Jonathan Taylor < jonathan.taylor@stanford.edu> wrote:
Yes, it's a dense 2500x2000 matrix.
Loaded strides: (8, 16000)
Copied strides: (20000, 8)
So, matvec is just slower because of strides and where numpy retrieves
data? Is there a simple way to do this besides a copy? I can easily afford the copy, just wondering.
It's not simpler, but the most efficient and idiomatic way to ensure C-contiguity is to use np.ascontiguousarray(). This will make a copy only if necessary.
-- Robert Kern
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@python.org https://mail.python.org/mailman/listinfo/scipy-dev
-- Jonathan Taylor Dept. of Statistics Sequoia Hall, 137 390 Serra Mall Stanford, CA 94305 Tel: 650.723.9230 Fax: 650.725.8977 Web: http://www-stat.stanford.edu/~jtaylo