Prev: Curve fitting MIMO grey-box model using pem and freq. data
Next: (web + urlread) empty page from google scholar
From: Loren Shure on 3 May 2010 13:55
In article <TiDDn.119030$kj3.70607(a)newsfe08.iad>, roberson(a)hushmail.com
says...
> Juliette Salexa wrote:
>
> > I don't think I am understanding you though.
> > I didn't use the JIT compiler at all (at least I don't think I did, I
> > don't even know what it is)
>
> The Just In Time compiler (JIT) is always active for functions (but not
> scripts or the command line), unless you specifically turn it off. The
> JIT parses the human-readable code and creates an in-memory version of
> the code that is in an internal binary language. The JIT cross-analyzes
> the code across multiple lines and tries to figure out the most
> efficient way of handling the function as a whole. When it can deduce
> enough about what is going on, it will make calls to the most specific
> routine that it knows about to handle the work. If, however, the code is
> too complex for it, or if it has not seen enough information to know
> what the optimal routine would be, then instead it uses more general
> (slower) internal routines.
>
> As a small example: there are routines that are optimized for adding
> together integer data-types (e.g., uint32), and there are routines that
> are optimized for adding together double precision numbers. If the JIT
> is able to deduce that two arrays being added are double precision, it
> can directly call the double-precision routine, and if it can deduce
> that they are particular kinds of integers, then it can directly call
> the appropriate integer routine, but if the JIT does not have enough
> information, it will have to use code that first has to figure out what
> kinds of numbers are being added -- which will be slower than optimal.
>
> As I mentioned, the JIT does not come into effect for things done at the
> command line or in scripts: Matlab always uses the most general routine
> in that case, and thus (barring bugs in the JIT), scripts and the
> command line will fairly like be slower than the same code in functions.
>
> > Also, are you saying that it would be faster to split the line
> > m(:,1)=ceil(h(:)/4^1)+ceil(h(:)/4^2)+ceil(h(:)/4^11);
> > into three separate lines:
>
> You had a line that started with tic, then a semi-colon, then a command,
> then a semi-colon, then a toc. Splitting that up into three lines,
>
> tic
> the command
> toc
>
> is better, because the JIT is known to have difficulty optimizing the
> commands when there are several different commands on the same line.
>


Actually, the information about the JIT is not strictly correct for
R2010a. Many releases have had improvements and scripts (and I think
the command-line) can now be JIT'ed. That doesn't mean there aren't
performance differences in the different realms, but more code is
JITable in more situations over time. For best consistent performance,
placing code in functions is a good bet.

--
Loren
http://blogs.mathworks.com/loren
http://matlabwiki.mathworks.com/MATLAB_FAQ
First  |  Prev  | 
Pages: 1 2
Prev: Curve fitting MIMO grey-box model using pem and freq. data
Next: (web + urlread) empty page from google scholar