Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Wow, Python much faster than MatLab

Reply
Thread Tools

Wow, Python much faster than MatLab

 
 
Stef Mientki
Guest
Posts: n/a
 
      12-29-2006
hi All,

instead of questions,
my first success story:

I converted my first MatLab algorithm into Python (using SciPy),
and it not only works perfectly,
but also runs much faster:

MatLab: 14 msec
Python: 2 msec

After taking the first difficult steps into Python,
all kind of small problems as you already know,
it nows seems a piece of cake to convert from MatLab to Python.
(the final programs of MatLab and Python can almost only be
distinguished by the comment character

Especially I like:
- more relaxed behavior of exceeded the upper limit of a (1-dimensional)
array
- much more functions available, like a simple "mean"
- reducing datatype if it's allowed (booleans of 1 byte)

thanks for all your help,
probably need some more in the future,
cheers,
Stef Mientki
 
Reply With Quote
 
 
 
 
Beliavsky
Guest
Posts: n/a
 
      12-30-2006

Stef Mientki wrote:
> hi All,
>
> instead of questions,
> my first success story:
>
> I converted my first MatLab algorithm into Python (using SciPy),
> and it not only works perfectly,
> but also runs much faster:
>
> MatLab: 14 msec
> Python: 2 msec


For times this small, I wonder if timing comparisons are valid. I do
NOT think SciPy is in general an order of magnitude faster than Matlab
for the task typically performed with Matlab.

>
> After taking the first difficult steps into Python,
> all kind of small problems as you already know,
> it nows seems a piece of cake to convert from MatLab to Python.
> (the final programs of MatLab and Python can almost only be
> distinguished by the comment character
>
> Especially I like:
> - more relaxed behavior of exceeded the upper limit of a (1-dimensional)
> array


Could you explain what this means? In general, I don't want a
programming language to be "relaxed" about exceeding array bounds.

 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      12-30-2006
On Fri, 29 Dec 2006 19:35:22 -0800, Beliavsky wrote:

>> Especially I like:
>> - more relaxed behavior of exceeded the upper limit of a (1-dimensional)
>> array

>
> Could you explain what this means? In general, I don't want a
> programming language to be "relaxed" about exceeding array bounds.


I'm not sure about SciPy, but lists in standard Python allow this:

>>> array = [1, 2, 3, 4]
>>> array[2:50000]

[3, 4]

That's generally a good thing.




--
Steven.

 
Reply With Quote
 
Stef Mientki
Guest
Posts: n/a
 
      12-30-2006

>> MatLab: 14 msec
>> Python: 2 msec

>
> For times this small, I wonder if timing comparisons are valid. I do
> NOT think SciPy is in general an order of magnitude faster than Matlab
> for the task typically performed with Matlab.

The algorithm is meant for real-time analysis,
where these kind of differences counts a lot.
I'm also a typical "surface programmer"
(don't need/want to know what's going inside),
just want to get my analysis done,
and the fact that Python has much more functions available,
means I've to write far less explicit or implicit for loops,
and thus I expect it to "look" faster for me always.
>
>> After taking the first difficult steps into Python,
>> all kind of small problems as you already know,
>> it nows seems a piece of cake to convert from MatLab to Python.
>> (the final programs of MatLab and Python can almost only be
>> distinguished by the comment character
>>
>> Especially I like:
>> - more relaxed behavior of exceeded the upper limit of a (1-dimensional)
>> array

>
> Could you explain what this means? In general, I don't want a
> programming language to be "relaxed" about exceeding array bounds.
>

Well, I've to admit, that wasn't a very tactic remark, "noise" is still
an unwanted issue in software.
But in the meanwhile I've reading further and I should replace that by
some other great things:
- the very efficient way, comment is turned into help information
- the (at first sight) very easy, but yet quit powerfull OOPs implemetation.

cheers,
Stef Mientki
 
Reply With Quote
 
Stef Mientki
Guest
Posts: n/a
 
      12-30-2006
>
> I'm not sure about SciPy,


Yes SciPy allows it too !
but lists in standard Python allow this:
>
>>>> array = [1, 2, 3, 4]
>>>> array[2:50000]

> [3, 4]
>
> That's generally a good thing.
>


You're not perhaps by origin an analog engineer

cheers,
Stef Mientki
 
Reply With Quote
 
Mathias Panzenboeck
Guest
Posts: n/a
 
      12-30-2006
A other great thing: With rpy you have R bindings for python.
So you have the power of R and the easy syntax and big standard lib of python!
 
Reply With Quote
 
Stef Mientki
Guest
Posts: n/a
 
      12-30-2006
Mathias Panzenboeck wrote:
> A other great thing: With rpy you have R bindings for python.


forgive my ignorance, what's R, rpy ?
Or is only relevant for Linux users ?

cheers
Stef

> So you have the power of R and the easy syntax and big standard lib of python!

 
Reply With Quote
 
John J. Lee
Guest
Posts: n/a
 
      12-30-2006
Stef Mientki <(E-Mail Removed)> writes:

> Mathias Panzenboeck wrote:
> > A other great thing: With rpy you have R bindings for python.

>
> forgive my ignorance, what's R, rpy ?
> Or is only relevant for Linux users ?

[...]

R is a language / environment for statistical programming. RPy is a
Python interface to let you use R from Python. I think they both run
on both Windows and Linux.

http://www.r-project.org/

http://rpy.sourceforge.net/


John
 
Reply With Quote
 
sturlamolden
Guest
Posts: n/a
 
      12-31-2006

Stef Mientki wrote:

> MatLab: 14 msec
> Python: 2 msec


I have the same experience. NumPy is usually faster than Matlab. But it
very much depends on how the code is structured.

I wonder if it is possible to improve the performance of NumPy by
having its fundamental types in the language, instead of depending on
operator overloading. For example, in NumPy, a statement like

array3[:] = array1[:] + array2[:]

allocates an intermediate array that is not needed. This is because the
operator overloading cannot know if it's evaluating a part of a larger
statement like

array1[:] = (array1[:] + array2[:]) * (array3[:] + array4[:])

If arrays had been a part of the language, as it is in Matlab and
Fortran 95, the compiler could see this and avoid intermediate storage,
as well as looping over the data only once. This is one of the main
reasons why Fortran is better than C++ for scientific computing. I.e.
instead of

for (i=0; i<n; i++)
array1[i] = (array1[i] + array2[i]) * (array3[i] + array4[i]);

one actually gets something like three intermediates and four loops:

tmp1 = malloc(n*sizeof(whatever));
for (i=0; i<n; i++)
tmp1[i] = array1[i] + array2[i];
tmp2 = malloc(n*sizeof(whatever));
for (i=0; i<n; i++)
tmp2[i] = array3[i] + array4[i];
tmp3 = malloc(n*sizeof(whatever));
for (i=0; i<n; i++)
tmp3[i] = tmp1[i] + tmp2[i];
free(tmp1);
free(tmp2);
for (i=0; i<n; i++)
array1[i] = tmp3[i];
free(tmp3);

In C++ this is actually further bloated by constructor, destructor and
copyconstructor calls.
Why one should use Fortran over C++ is obvious. But it also applies to
NumPy, and also to the issue of Numpy vs. Matlab, as Matlab know about
arrays and has a compiler that can deal with this, whilst NumPy depends
on bloated operator overloading. On the other hand, Matlab is
fundamentally impaired on function calls and array slicing compared
with NumPy (basically copies are created instead of views). Thus, which
is faster - Matlab or NumPy - very much depends on how the code is
written.

Now for my question: operator overloading is (as shown) not the
solution to efficient scientific computing. It creates serious bloat
where it is undesired. Can NumPy's performance be improved by adding
the array types to the Python language it self? Or are the dynamic
nature of Python preventing this?

Sturla Molden

 
Reply With Quote
 
Robert Kern
Guest
Posts: n/a
 
      12-31-2006
sturlamolden wrote:
> array3[:] = array1[:] + array2[:]


OT, but why are you slicing array1 and array2? All that does is create new array
objects pointing to the same data.

> Now for my question: operator overloading is (as shown) not the
> solution to efficient scientific computing. It creates serious bloat
> where it is undesired. Can NumPy's performance be improved by adding
> the array types to the Python language it self? Or are the dynamic
> nature of Python preventing this?


Pretty much. Making the array types builtin rather than from a third party
module doesn't really change anything. However, if type inferencing tools like
psyco are taught about numpy arrays like they are already taught about ints,
then one could do make it avoid temporaries.

--
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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
vectorized computation in C++ such as those in Matlab (Matlab toC++)? Luna Moon C++ 16 08-08-2008 04:27 PM
Eclipse RCP and MATLAB (calling MATLAB from JAVA) siki Java 0 01-16-2007 04:19 AM
RE: Wow, Python much faster than MatLab Doran, Harold Python 10 01-01-2007 06:56 PM
Is a Java Application much faster than an Applet. Sanny Java 12 12-15-2006 02:47 AM
Matplotlib in Python vs. Matlab, which one has much better graphicalpressentation? N/A Python 2 05-11-2006 10:03 PM



Advertisments