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:
https://code.google.com/p/python-matlab-wormholes/
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@xxxxxxxxxxxxx> 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 egaudrain.cam@xxxxxxxxx.