Path: news.mathworks.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!newsswitch.lcs.mit.edu!newsfeed.cwix.com!dc3peer2.nntp.savvis.net!peer.nntp.savvis.net!cycny02.gnilink.net!cyclone1.gnilink.net!gnilink.net!nx02.iad.newshosting.com!newshosting.com!69.16.185.11.MISMATCH!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post01.iad.highwinds-media.com!newsfe10.iad.POSTED!7564ea0f!not-for-mail
From: Walter Roberson <roberson@hushmail.com>
Organization: Canada Eat The Cookie Foundation
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
Newsgroups: comp.soft-sys.matlab
Subject: Re: much faster MATLAB
References: <gcebi7$otk$1@fred.mathworks.com> <5b415775-2638-43ed-a84a-6de4ebeea927@d45g2000hsc.googlegroups.com> <gcfv2a$b1v$1@fred.mathworks.com>
In-Reply-To: <gcfv2a$b1v$1@fred.mathworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 39
Message-ID: <mAMGk.1706$jf4.937@newsfe10.iad>
NNTP-Posting-Host: 24.79.146.116
X-Complaints-To: internet.abuse@sjrb.ca
X-Trace: newsfe10.iad 1223398802 24.79.146.116 (Tue, 07 Oct 2008 17:00:02 UTC)
NNTP-Posting-Date: Tue, 07 Oct 2008 17:00:02 UTC
Date: Tue, 07 Oct 2008 12:00:37 -0500
Xref: news.mathworks.com comp.soft-sys.matlab:494108


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.)