Prev: shade some zones for emphasis
Next: matlab functions
From: Paul Huber on 26 Apr 2010 21:55
Let me clarify ... we (some coleagues, not important here) were discussing
how matlab is nice and everything (it is really), but at one point in terms of
size of data it needs to process, or speed of doing it, it becomes a restriction
as compared to let's say fortran.

Then another fellow asked, at what point does it ? What would be the number of
data I can "normally" process under matlab, and when is the "jumping point" when
I would need to switch to let's say fortran.

I was a little suprised, and didn't know.

So, I'm asking you, while keeping in mind that I'm not interested in "matlab is the best",
or "fortran all the way" and alike arguments, what do you say to this ? Rational arguments
are valued more than any, as well as practical cases.

with regards to all,
Paul
From: Jan Simon on 28 Apr 2010 16:34
Dear Paul!

> Then another fellow asked, at what point does it ? What would be the number of
> data I can "normally" process under matlab, and when is the "jumping point" when
> I would need to switch to let's say fortran.

For me, Matlab is the first choice if the time for programming exceeds the time of running a program. The program development in Matlab is very clear and fast, if you can solve a problem using an existing well tested toolbox function.

If the runtime of a program exceeds the time needed for programming and debugging, I choose Fortran, C or C++.
Programming a function is C needs usually more time, because the number of needed lines e.g. for vector/matrix and string manupulations is much higher.

Example:
If I want to calculate *some* SVDs, I let Matlab do the stuff:
[U, S, V] = svd(X);
Fortunately Matlab calls the well tested LAPACK routines for that.

If I need millions of SVDs for a parameter estimation, I let a C-function call LAPACK directly to avoid the overhead times:
dgesvd_(jobu, jobvt, m, n, A, LDA, S, U, LDU, VT, work, lwork, info);
Of course I have to find the correct sizes for [work] and [lwork] before. And I admit that I have to lookup the calling parameters in a table each time, while I'm really able to remember the Matlab calling conventions of SVD.

Matlab is very efficient for rapid prototyping. Actually its speed could compete with C and Fortran if large arrays are processed - because it calls e.g. the same BLAS/LAPACK/ATLAS routines as it is recommended for the other low-level languages as well-, but the memory handling is suboptimal:
- You cannot force inplace matrix calculations (although Matlab does it automatically *sometimes* under *certain* conditions).
- You cannot allocate uninitialized memory, when you call C-Mex functions from Matlab: mxMalloc replies memory initialized with zeros - as mxCalloc.

My summary for efficient programming:
programming time + debug time >> runtime ==> Matlab
I'm programming for 30 years now, and I've personally seen just 2 programs with runtime >> debug time: The optimization of a walking robot for the PhD of Thorsten Stossmeister and seti(a)home.
(If you now want to mention folding(a)home, MD5crack etc., let me guess, if they are implemented in Matlab...)

Kind regards, Jan
 | 
Pages: 1
Prev: shade some zones for emphasis
Next: matlab functions