Thread Subject: much faster MATLAB

All,

I have been using MATLAB for many years now but finally its speed has become a major limiting factor. As time has gone on, large segments of my code are no longer in need of further development (though other segments are). These same segments are the ones that consume most of the computation time.

Mex files are the solution I suppose; however the last time I programmed in Fortran was 30 years ago, and in C, never. In reading about mex files, it sounds daunting for a basically amateur (in terms of skills) programmer like me.

In a broad sense, what would be the best approach to substantially (at least 10x) speed up these unchanging swaths of code, for someone who is not a programmer? I'd be able to invest in a solution within reason.

Thanks

 

"Kevin Johnson" <defer.jof@gmail.com> wrote in message <gcebi7$otk$1@fred.mathworks.com>...
> All,
>
> I have been using MATLAB for many years now but finally its speed has become a major limiting factor. As time has gone on, large segments of my code are no longer in need of further development (though other segments are). These same segments are the ones that consume most of the computation time.
>
> Mex files are the solution I suppose; however the last time I programmed in Fortran was 30 years ago, and in C, never. In reading about mex files, it sounds daunting for a basically amateur (in terms of skills) programmer like me.
>
> In a broad sense, what would be the best approach to substantially (at least 10x) speed up these unchanging swaths of code, for someone who is not a programmer? I'd be able to invest in a solution within reason.
>
> Thanks
>
>

Mex files are not always the solution. Improving the MATLAB implementation can offer orders of magnitude increase in performance when a particularly poor choice has been made (ie arrays growing in loops etc).

I would recommend that you run your code through the MATLAB Profiler and identify the regions of poorly performing code. Look at any MLint messages from those code blocks, try and find more efficient implementations of the algorithms.

And sometimes it just takes a certain period of time to do particular operations independent of the implementation language. In that case, buy a faster CPU!

Cheers

Rod

--
http://iheartmatlab.blogspot.com

On Oct 6, 11:10=A0pm, "Rodney Thomson"
<readm...@iheartmatlab.blogspot.com> wrote:
> "Kevin Johnson" <defer....@gmail.com> wrote in message <gcebi7$ot...@fred=
.mathworks.com>...
> > All,
>
> > I have been using MATLAB for many years now but finally its speed has b=
ecome a major limiting factor. =A0As time has gone on, large segments of my=
 code are no longer in need of further development (though other segments a=
re). These same segments are the ones that consume most of the computation =
time.
>
> > Mex files are the solution I suppose; however the last time I programme=
d in Fortran was 30 years ago, and in C, never. In reading about mex files,=
 it sounds daunting for a basically amateur (in terms of skills) programmer=
 like me.
>
> > In a broad sense, what would be the best approach to substantially (at =
least 10x) speed up these unchanging swaths of code, for someone who is not=
 a programmer? =A0I'd be able to invest in a solution within reason.
>
> > Thanks
>
> Mex files are not always the solution. Improving the MATLAB implementatio=
n can offer orders of magnitude increase in performance when a particularly=
 poor choice has been made (ie arrays growing in loops etc).
>
> I would recommend that you run your code through the MATLAB Profiler and =
identify the regions of poorly performing code. Look at any MLint messages =
from those code blocks, try and find more efficient implementations of the =
algorithms.
>
> And sometimes it just takes a certain period of time to do particular ope=
rations independent of the implementation language. In that case, buy a fas=
ter CPU!
>
> Cheers
>
> Rod
>
> --http://iheartmatlab.blogspot.com

Rod's probably right here. If you spend a little time to learn
Matlab's logical indexing and linearizing methods, you can write
wicked fast code, without having to resort to a compiled language.
However, if you'd rather dip into Fortran and C, knock yourself out.

On 7 Okt, 02:47, "Kevin Johnson" <defer....@gmail.com> wrote:
> All,
>
> I have been using MATLAB for many years now but finally its speed has bec=
ome a major limiting factor. =A0As time has gone on, large segments of my c=
ode are no longer in need of further development (though other segments are=
). These same segments are the ones that consume most of the computation ti=
me.

You might want to profile the code and see exactky where the
bottlenecks are. After that, you might want to look into the
time-consuming parts and see what goes on in there. If they
are plain-vanilla matrix operations there is likely not much
you can do to speed things up - you might possibly gain something
by using parallel libraries in a multi-core CPU, depending on
your present hardware. If you findbottlenecks in I/O, work flow
organization etc, you can expect 10x improvment if you switch
to a language like C++.

> Mex files are the solution I suppose; however the last time I programmed =
in Fortran was 30 years ago, and in C, never. In reading about mex files, i=
t sounds daunting for a basically amateur (in terms of skills) programmer l=
ike me.

It's for sure not something to be taken lightly. On the
other hand, you will not find any better motivation to
learn than your present frustration.

> In a broad sense, what would be the best approach to substantially (at le=
ast 10x) speed up these unchanging swaths of code, for someone who is not a=
 programmer? =A0I'd be able to invest in a solution within reason.

If you are not a programmer by training yourself, then you
might want to consult somebody who is. It takes time and
dedication to learn how to program efficiently, and it might
be too large a commitment to take on, if you only want to
modify some existing code.

If somebody seriously considers to learn Fortran or C in order
to program MEX files, I would suggest they consider C++. It is
a far more flexible language than either Fortran or C, so one
can do far more advanced stuff, and everything is way easier.

The downside with C++ is that one needs a C++ compiler to use
with matlab (matlab comes with a C compiler), and C++ takes
a long time to learn.

Rune

Rune and Rod,

First of all, thank you very much for taking the time to answer.

I run Profiler routinely to look for bottlenecks and have indeed found many. I also have vectorized for loops where I can figure out how to do so.

Would it be correct to say that where CPU usage is the problem, only a faster CPU (or parallel computing) would help, whereas with most everything else mex files would be substantially faster?

How would I go about finding a professional programmer to help me, if it comes to that?

Thanks
Kevin

On 7 Okt, 17:26, "Kevin Johnson" <defer....@gmail.com> wrote:

> Would it be correct to say that where CPU usage is the problem, only a faster CPU (or parallel computing) would help, whereas with most everything else mex files would be substantially faster?

Yes, but be aware that the CPU probably works flat out
already, regardless of what causes the bottleneck. You
might not be able to identify improvable code very
easily.

> How would I go about finding a professional programmer to help me, if it comes to that?

I have no idea.

Rune

Kevin Johnson wrote:
 
> Would it be correct to say that where CPU usage is the problem, only a faster CPU (or
> parallel computing) would help, whereas with most everything else mex files would be
> substantially faster?

No, I wouldn't say so. If you are I/O bound, for example, then with a MEX file you
are -still- going to be I/O bound (though with some operating systems and for some
kinds of data access patterns, you might be able to use "scatter/gather I/O"
to improve I/O performance.)

These days, with Matlab's Just In Time (JIT) compiler, Matlab might not be as
fast as a really good optimizing compiler, but when the operations have been
chosen wisely, it is often better than "plain" C or C++ that has not been
specifically designed for high performance.

C or C++ code that -has- been specifically designed for high performance has to
rely upon system-specific knowledge or extensions: the C and C++ programming
languages describe abstract operation models and have no inherent mechanisms to
(for example) say "Allocate two blocks of memory for me, both such and such a
size, but align them in such a way that if I access them both sequentially with
a stride of such-and-such, that I will not have any cache line collisions between the
two arrays". And the C and C++ languages do not have ways to express,
"Compile the following block of code so that the floating point operations are
done on a SSE3 co-processor." Thus high-performance C or C++ code is not portable
code: you have to cheat on the promises made by the programming languages in order
to get the performance.

The potential performance difference between MATLAB and C or C++ is based upon
the fact that MATLAB hides all of its performance tricks under the covers, whereas
when you use C or C++ you have an opportunity to make them explicit. For example, does
MATLAB take cache effects into account when calculating A+B for matrices? You don't
know and you can't find out, not unless you know that whatever operation you are doing
is handed over to BLAS and you have the BLAS source available along with the list
of options that BLAS was compiled with for your particular processor. But lack
of information about what MATLAB is doing to maintain performance doesn't mean that
MATLAB is -not- taking measures to optimize performance: it just means you don't know
-what- measures it is taking, and the measures might change from version to version
(possibly making some situations worse instead of better.)

Kevin Johnson <defer.jof@gmail.com> wrote:
[snip]
>
> Would it be correct to say that where CPU usage is the problem, only a
faster CPU (or parallel computing) would help, whereas with most everything
else mex files would be substantially faster?

No. See other peoples comments for some good points on this.

You are not going to get any specific answers, though, unless you share
some specific code.


>
> How would I go about finding a professional programmer to help me, if it
comes to that?
>

You could drop me an email with some more details.

--
Dr Tristram J. Scott
Energy Consultant

"Kevin Johnson" <defer.jof@gmail.com> wrote in message <gcebi7$otk$1@fred.mathworks.com>...
> All,
>
> I have been using MATLAB for many years now but finally its speed has become a major limiting factor. As time has gone on, large segments of my code are no longer in need of further development (though other segments are). These same segments are the ones that consume most of the computation time.
>
> Mex files are the solution I suppose; however the last time I programmed in Fortran was 30 years ago, and in C, never. In reading about mex files, it sounds daunting for a basically amateur (in terms of skills) programmer like me.
>
> In a broad sense, what would be the best approach to substantially (at least 10x) speed up these unchanging swaths of code, for someone who is not a programmer? I'd be able to invest in a solution within reason.


Some additional comments that may be relevant.

Files: Matlab didn't use to be that clever at file I/O. Or at data types other than double precision. Given some random file to read (e.g. from a simulation program or data analyser), MEX was the only sensible option. That may have changed now - I've not recently tried to read in huge amounts of data from a binary file. Many vendors will provide you with A C API to read their files, pretty much forcing you to use MEX.

Memory: Most data analysis I used to do involved very large datasets. The analysis was usually limited my memory. Fine-grained control over memory use was something that was absolutely necessary, but not possible with Matlab - too many intermediate copies of variables. To a certain extent, this is still true today.

System interaction: If you want access to base OS functions, you need to code in their language. In the UNIX environment, this is C. What you are really doing is extending Matlab rather than simply making it faster.

As far as speed goes, I've never really been involved with matrix maths. Most of my analysis is/was with very long 1D arrays. It was always simple to get good speedup over the built-in functions. Massive if you "crossed to the dark side" and started to modify things you weren't supposed to.

An anecdote: One of our departments based its whole analysis core on a load of MEX functions, using simple m-file scripts to shovel data between them. The original author left many years ago, leaving them unsupported and to a large extend, not even understood (neither the theory nor implementation). After a few years with their heads in the sand they seem to have decided to go back to the safer position of using MEX only where required rather than for fun.

My view: MEX files should not be used unless there is a competent (hopefully better than that) C programmer on board, preferably more than one (see above). Outsourcing them sounds like a suicidal tactic.

"Kevin Johnson" <defer.jof@gmail.com> writes:

> How would I go about finding a professional programmer to help me, if
> it comes to that?

If money is not an issue, you should't have problems with that.

--
Ralph Schleicher <http://ralph-schleicher.de>

Development * Consulting * Training
Mathematical Modeling and Simulation
Software Tools

"Kevin Johnson" <defer.jof@gmail.com> wrote in message <gcebi7$otk$1@fred.mathworks.com>...
> All,
>
> I have been using MATLAB for many years now but finally its speed has become a major limiting factor. As time has gone on, large segments of my code are no longer in need of further development (though other segments are). These same segments are the ones that consume most of the computation time.
>
> Mex files are the solution I suppose; however the last time I programmed in Fortran was 30 years ago, and in C, never. In reading about mex files, it sounds daunting for a basically amateur (in terms of skills) programmer like me.
>
> In a broad sense, what would be the best approach to substantially (at least 10x) speed up these unchanging swaths of code, for someone who is not a programmer? I'd be able to invest in a solution within reason.
>
> Thanks


Also, consider the possibility that writing, debugging, testing, debugging, optimizing, debugging, and running C++ code may actually take longer than just waiting for the Matlab code to run.

If I knew then what I know now, I wouldn't know anything about C++ and I'd be a year younger.

Charles
>

"Kevin Johnson" <defer.jof@gmail.com> wrote in message <gcebi7$otk$1@fred.mathworks.com>...
> All,
>
> I have been using MATLAB for many years now but finally its speed has become a major limiting factor. As time has gone on, large segments of my code are no longer in need of further development (though other segments are). These same segments are the ones that consume most of the computation time.
>
> Mex files are the solution I suppose; however the last time I programmed in Fortran was 30 years ago, and in C, never. In reading about mex files, it sounds daunting for a basically amateur (in terms of skills) programmer like me.
>
> In a broad sense, what would be the best approach to substantially (at least 10x) speed up these unchanging swaths of code, for someone who is not a programmer? I'd be able to invest in a solution within reason.
>
> Thanks
>

matlab2fmex would be an useful tool that help you turn your MATLAB code to Fortran MEX "automatically".
You can find it at https://sourceforge.net/projects/matlab2fmex/

"Kevin Johnson" <defer.jof@gmail.com> wrote in message <gcebi7$otk$1@fred.mathworks.com>...
> All,
>
> I have been using MATLAB for many years now but finally its speed has become a major limiting factor. As time has gone on, large segments of my code are no longer in need of further development (though other segments are). These same segments are the ones that consume most of the computation time.
>
> Mex files are the solution I suppose; however the last time I programmed in Fortran was 30 years ago, and in C, never. In reading about mex files, it sounds daunting for a basically amateur (in terms of skills) programmer like me.
>
> In a broad sense, what would be the best approach to substantially (at least 10x) speed up these unchanging swaths of code, for someone who is not a programmer? I'd be able to invest in a solution within reason.
>
> Thanks
>
>

There's also Embedded MATLAB that you can use to generate C code or a C-MEX file directly from a subset of MATLAB commands.

Embedded MATLAB
http://www.mathworks.com/access/helpdesk/help/toolbox/eml/eml_product_page.html

(Embedded MATLAB MEX)
http://www.mathworks.com/access/helpdesk/help/toolbox/eml/ug/bq2wkmb-1.html

If you're not concerned about getting the actual C-code, and just want a C-MEX file, then you can go with Embedded MATLAB MEX, which would require either Simulink and/or Fixed-Point Toolbox.

Here's where it talks about the Embedded MATLAB subset:
http://www.mathworks.com/access/helpdesk/help/toolbox/eml/ug/bq1h2z5-1.html

I disagree with the general opinion that it is hard to make faster code with MEX files. Matlab does not handle some cases efficiently.

For example, when working with large matrices:
A = zeros(n, n);
for j=1:many
  B = sparse(n, n, 0.01);
  A = A + B;
end

So, adding a sparse matrix to a full matrix, many times. Matlab first creates a temporary matrix T = A+B, and then assigns A:=T, deleting the previous A from memory. For large matrices, this reallocating consumes considerable time.

Writing a simple MEX file that overwrites the data in A:
MexAddMatrix(A,B);
bypasses the memory allocation for A.

MEX files can also speedup many elementary numerical work, e.g. raytraycing.

Greetings,
Sebastiaan