Re: Python from Matlab (Etienne Gaudrain )

Subject: Re: Python from Matlab
From:    Etienne Gaudrain  <e.p.c.gaudrain@xxxxxxxx>
Date:    Mon, 25 Aug 2014 09:30:21 +0200

Hi Jont, There are a few benchmarks around (although results change very quickly), and Dan can probably comment more on this. My experience is that default Scipy/Numpy packages are generally on a par or a bit slower than Matlab. But on big projects with a lot of nested function calls or GUI elements Matlab quickly becomes slow (or at least that was the case in the pre-JIT days, don't know how it is now). The fact that you can explicitly control thread in Python can also help making things much more efficient (without the need of a terrible expensive toolbox), especially for realtime processing. But I think what makes Python glamorous (for those who need it) is the possibility to include C code, directly in the Python file, for things that need to be very fast. That's more elegant than doing a mex file. And of course you can also recompile Numpy and Scipy on your machine for a bit of extra performance. But to be fair I'm probably not the best person to answer this as I generally only use Python for things Matlab is really poor at: - GUI programming (because you want a properly object-oriented language for that, with clear thread handling) - Text manipulations (or actually any data manipulation that's not in native Matlab format) - Figure plotting (because Matlab is so painfully limited) - Any general purpose task for which a signal-processing oriented language is not suited for Typically, when I program an auditory experiment, I use Matlab if I need a very basic GUI, but Python if I need anything a bit more fancy. I use Matlab for all the signal processing (real time or not) and sound presentation. Then I use Matlab for data pre-processing and Python and R for data analysis/plotting. If I didn't depend on things like STRAIGHT, or until now, auditory models, I would probably switch altogether to Python to simplify my working environment and save the cost of a Matlab license. Best, -Etienne On 24/08/2014 18:20, Jont Allen wrote: > Etienne > What was your feeling about the relative performance of matlab vs > python, computationally? > Jont > > On 08/23/2014 03:38 PM, Etienne Gaudrain wrote: >> Hi Alain, >> >> The few times I had to do that, I actually programmed everything in >> Python using mlabwrap, and called the script with a system command from >> Matlab... >> >> Another option seem to be using JPython, the Java implementation of >> Python, which can be fully integrated in Matlab's Java interface, but I >> must admit I have no clue how (and I hear that not all libraries are >> implemented in JPython). >> >> Otherwise, it looks like someone wrote a client/server interface: >> >> Haven't tried it though. >> >> Good luck! >> -Etienne >> >> >> On 22/08/2014 23:30, Alain de Cheveigne wrote: >>> [To list members not interested in Matlab, etc.: apologies for the >>> annoyance. The discussion is somewhat relevant to audition, in that >>> modeling, experiment control, and data analysis increasingly rely on >>> computers, and the choice of a high-quality computation environment >>> is crucial.] >>> Hi Jan, >>> >>> A client/server solution indeed sounds ideal. I don't know what it >>> involves in terms of programming effort, but I'm sure that effort >>> would be well spent. >>> >>> The ideal solution would be: >>> - simple to use, like calling >>> "result=toPython('pythonFunction',arguments);" >>> - efficient, i.e. minimal overhead for data transfer, >>> - reliable, system-independent, and future-proof, >>> - secure. >>> >>> Several people mentioned calling Python via a shell command, passing >>> values by file, etc. I'm concerned that these solutions might >>> involve greater overhead, more complex syntax, possibly greater >>> system dependencies, and possibly security issues. >>> >>> Alain >>> >>> >>> >>> On 22 Aug 2014, at 13:47, Jan Schnupp <jan.schnupp@xxxxxxxx> >>> wrote: >>> >>>> Or you could >>>> python and matlab work together on some sort of client/server model. >>>> That would be more elegant - the matlab and python parts then wouldn't >>>> even have to be on the same machine, but the programming investment is >>>> very large. I don't know of any developments to make this sort of >>>> stuff easier that are even on the distant horizon. If other list >>>> members know of any I would be interested to hear about them. -- Etienne Gaudrain, PhD UMCG, Afdeling KNO, BB20 PO Box 30.001 9700 RB Groningen, NL Room P3.236 Phone +31 5036 13290 Skype egaudrain Note: emails to this address are limited to 10 MB. To send larger files, use

This message came from the mail archive
maintained by:
DAn Ellis <>
Electrical Engineering Dept., Columbia University