[SciPy-user] MATLAB code faster than Python!

Robert Kern robert.kern at gmail.com
Mon Jul 3 17:45:42 EDT 2006


William Hunter wrote:
> Yes, it's true. Using MATLAB's <profile> and IPython's <prun> there is 
> at least some agreement
> of where the code is consuming time. What I find strange is the type of 
> operation that's causing this.
>  
> Below is the "culprit line" (MATLAB):
> K(edof,edof) = K(edof,edof) + x(ely,elx)^penal*Kel;
>  
> In Python I wrote this as:
> K[ix_(edof,edof)] += x[ely,elx]**penal*Kel
>  
> Both lines are nested inside two <for> loops. How is it possible that 
> MATLAB is faster (by a factor
> of at least 2.25), or am I naive to think it will be otherwise?!

You should not use profiled times to compare implementations. You should only 
use them to identify hotspots in your code. Profiling involves instrumenting 
your code, and that affects the timing. Generally, relationships between times 
of functions A and B called in the same profile run will be the same as if there 
were no profiling. However, A and A' (the same as A but in a different language 
using a different profiling harness) won't be.

Without knowing any of the context (the size of K, what edof, el[xy], penal, and 
Kel are, how many times you are executing this line, etc.), I have no idea 
whether Matlab is actually faster or how to improve the Python code.

> <prun> also reports a function 0:(dgesv) that takes up a lot of time, 
> and I'm certain it is connected
> to my "culprit line" in some way...

dgesv is a LAPACK function that calculates singular values. It is called by 
linalg.svd(). If the size of the input is substantial, it is reasonable that 
this might take up a chunk of time.

> Can it be that <for> loops are slow in Python, if so, what else can I do?
> Unfortunately I HAVE to use a <for> as it updates an array, i.e., it's 
> not possible to make use of a static one.

Well, we can't really do anything for you. You haven't shown us enough code to 
make sense of your results much less to offer specific suggestions.

However, in general terms, you should break out the pieces of code that you 
think are problematic into separate benchmarks.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



More information about the SciPy-User mailing list