One Jacket programmer recently emailed the following to us:
<blockquote>Our chief scientists asked me a question that I'd like to pass on to you.  I think I know the answer, but you guys can be much more definitive than I can.

He recently read about people achieving ~10x speedups by converting parts of their code to MEX files.  He was wondering how much of the observed speedup is due to that MEX and how much is due to CUDA and the GPU.</blockquote>
<h3>Two Questions You Should Ask Yourself</h3>
When contemplating an effort to optimize a piece of code, it is important to unravel the effort into two separate questions.  Both need to be addressed to improve performance:
<ol>
	<li>How well-written is the code, given the language, hardware, and software libraries used?</li>
	<li>Is there a better platform (comprised of the language, hardware, and software libraries) for the problem?</li>
</ol>
<h3>Understanding the Two Questions</h3>
Holding the underlying language, hardware, and software libraries constant, speedups can often be attained simply by writing better code more tuned to the environment.  For instance, MATLAB code almost always benefits from vectorization modifications and the associated removal of FOR-loops.  MathWorks recommends <a href="http://www.mathworks.com/support/tech-notes/1100/1109.html" target="_blank">vectorization</a>.  We provide examples in our <a href="http://wiki.accelereyes.com/wiki/index.php/Code_Vectorization_Examples" target="_blank">documentation</a> too.  <a href="http://www.accelereyes.com/resources/spectroscopy" target="_blank">Researchers at Northeastern University</a> saw 100-fold speedups through vectorization efforts alone.

It is impossible to generically state that writing better code will result in a certain amount of performance improvement.  The more awful the original code, the more you stand to gain from this effort.

<!--more-->
<h3>Changing the Platform</h3>
Oftentimes, the underlying language, hardware, or software libraries are  not sufficient to produce the intended result, no matter how  well-written the code may be.  In this case, you will want to search for  a better platform.  For  instance, GPUs are really good at exploiting data-parallelism.  So if  you are working with matrices or vectors containing over 10,000  elements, GPUs are probably going to help.

Of course, if you decide that there is a better language/HW/SW platform, you will need to revisit Question #1 to ensure that your code is well-written for the new platform.

It is a happy synergy that both CPU-based MATLAB and GPU-based Jacket work better on vectorized code.  So any code optimizations made for one platform benefits the other.
<h3>Should I rewrite my "M functions as MEX functions"?</h3>
Now, given the framework of these 2 questions, we see that the "M functions vs MEX functions" inquiry boils down to whether or not it makes sense to change the platform.  In the search for faster MATLAB code, there are two options you might consider, separated by a large degree of difficulty:
<table border="0" cellspacing="0" cellpadding="0" width="657"><col span="2" width="75"></col> <col width="197"></col> <col width="310"></col>
<tbody>
<tr height="21">
<td width="95" height="21"><strong>Platform</strong></td>
<td width="95"><strong>Difficulty</strong></td>
<td width="207"><strong>CPU   optimizations</strong></td>
<td width="300"><strong>Data-Parallel   Optimizations</strong></td>
</tr>
<tr height="40">
<td height="40">C/CUDA</td>
<td>Harder</td>
<td>Re-write FOR-loops in   C/MEX</td>
<td>Exploit   parallelism with CUDA.  Integrate into   MATLAB with the Jacket SDK and GFOR.</td>
</tr>
<tr height="40">
<td height="40">MATLAB</td>
<td>Easier</td>
<td>Vectorize code.</td>
<td>Exploit   parallelism with Jacket data types and GFOR.</td>
</tr>
</tbody>
</table>
As mentioned previously, any change of platform requires a revisiting of Question #1 to ensure the code is well-written.  Keep in mind that CUDA is tough.
<h3>Conclusions</h3>
In the end, the speedups achieved from an optimization effort depend on how well the code is written for the underlying platform and on how well that underlying platform is able to exploit parallelism in the problem.