Thanks for the replies so far. I had already tested using an already transposed matrix in the loop, it didn't make any difference. Oh and btw, I'm on (Scientific) Linux.
I used the Enthought distribution, but I guess I'll have to get my hands dirty and try to get that Atlas thing working (I'm not a Linux expert though). My simulations pretty much consist of matrix multiplications, so if I don't get rid of that factor 5, I pretty much have to get back to Matlab. When you said Atlas is going to be optimized for my system, does that mean I should compile everything on each machine separately? I.e. I have a not-so-great desktop machine and one of those bigger multicore things available... Cheers David Quoting David Cournapeau <da...@ar.media.kyoto-u.ac.jp>: > David Warde-Farley wrote: >> On 4-Jun-09, at 5:03 PM, Anne Archibald wrote: >> >> >>> Apart from the implementation issues people have chimed in about >>> already, it's worth noting that the speed of matrix multiplication >>> depends on the memory layout of the matrices. So generating B instead >>> directly as a 100 by 500 matrix might affect the speed substantially >>> (I'm not sure in which direction). If MATLAB's matrices have a >>> different memory order, that might be a factor as well. >>> >> >> AFAIK Matlab matrices are always Fortran ordered. >> >> Does anyone know if the defaults on Mac OS X (vecLib/Accelerate) >> support multicore? Is there any sense in compiling ATLAS on OS X (I >> know it can be done)? >> > > It may be worthwhile if you use a recent gcc and recent ATLAS. > Multithread support is supposed to be much better in 3.9.* compared to > 3.6.* (which is likely the version used on vecLib/Accelerate). The main > issue I could foresee is clashes between vecLib/Accelerate and Atlas if > you mix softwares which use one or the other together. > > For the OP question: recent matlab versions use the MKL, which is likely > to give higher performances than ATLAS, specially on windows (compilers > on that platform are ancient, as building atlas with native compilers on > windows requires super-human patience). > > David > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion