Thread Subject: Why wont mcc make a mex

OK so im reading "Technical Solutions" with solution ID:
1-15VWV from February 23 2007 for R2007a.

The lowdown of tech soln 1-15VWV:
My MEX-file, that was compiled using the MATLAB Compiler 2.1
(R12), runs more slowly than the M-file equivalent. However,
when I use optimizations, I see a significant speed improvement.

For example,


tic; squibo(10000); toc

elapsed_time=
    2.230000

mcc squibo
tic; squibo(10000); toc;

elapsed_time=
  5.34000

mcc -ri squibo
tic; squibo(10000); toc

elapsed_time=
  0.083400

I just got my hands on the 2007b matlab compiler desperately
hoping to speed up some interpolation routines etc etc.

so i call mcc interp_function.m and it says
??? Error using ==> mcc
Unable to determine application type, since no wrapper
function was specified.
Please use the -W switch or specify application type via -m
or -l.
Type 'mcc -?' for further assistance.

The only thing i want to do is exactly what is in the
aforementioned "Technical Solution" and that's it!

Why the run around?

"Abel Brown" <brown.2179@osu.edu> schrieb im Newsbeitrag
news:fsscs7$88n$1@fred.mathworks.com...
> OK so im reading "Technical Solutions" with solution ID:
> 1-15VWV from February 23 2007 for R2007a.
>
> The lowdown of tech soln 1-15VWV:
> My MEX-file, that was compiled using the MATLAB Compiler 2.1
> (R12), runs more slowly than the M-file equivalent. However,
> when I use optimizations, I see a significant speed improvement.
>
> For example,
>
>
> tic; squibo(10000); toc
>
> elapsed_time=
> 2.230000
>
> mcc squibo
> tic; squibo(10000); toc;
>
> elapsed_time=
> 5.34000
>
> mcc -ri squibo
> tic; squibo(10000); toc
>
> elapsed_time=
> 0.083400
>
> I just got my hands on the 2007b matlab compiler desperately
> hoping to speed up some interpolation routines etc etc.
>
> so i call mcc interp_function.m and it says
> ??? Error using ==> mcc
> Unable to determine application type, since no wrapper
> function was specified.
> Please use the -W switch or specify application type via -m
> or -l.
> Type 'mcc -?' for further assistance.
>
> The only thing i want to do is exactly what is in the
> aforementioned "Technical Solution" and that's it!
>
> Why the run around?
>
>
>

Hi,
unfortunately you missed the first line of the solution:
"Note that compiling M-code to MEX-files is no longer supported with the
release of MATLAB Compiler 4.0 (R14)."
The compile does not convert to C-Code anymore but is more of a runtime
environment for the MATLAB code. Therefore converting to a MEX file would
not make sense at all, even if the compiler would do it.

Therefore: the profiler is the way to go
help profile
and try to speed up the code within MATLAB.

Hope this helps,
Titus

"Titus" <titus.edelhofer@mathworks.de> wrote in message
<fssq0b$g98$1@fred.mathworks.com>...
>
> "Abel Brown" <brown.2179@osu.edu> schrieb im Newsbeitrag
> news:fsscs7$88n$1@fred.mathworks.com...
> > OK so im reading "Technical Solutions" with solution ID:
> > 1-15VWV from February 23 2007 for R2007a.
> >
> > The lowdown of tech soln 1-15VWV:
> > My MEX-file, that was compiled using the MATLAB Compiler 2.1
> > (R12), runs more slowly than the M-file equivalent. However,
> > when I use optimizations, I see a significant speed
improvement.
> >
> > For example,
> >
> >
> > tic; squibo(10000); toc
> >
> > elapsed_time=
> > 2.230000
> >
> > mcc squibo
> > tic; squibo(10000); toc;
> >
> > elapsed_time=
> > 5.34000
> >
> > mcc -ri squibo
> > tic; squibo(10000); toc
> >
> > elapsed_time=
> > 0.083400
> >
> > I just got my hands on the 2007b matlab compiler desperately
> > hoping to speed up some interpolation routines etc etc.
> >
> > so i call mcc interp_function.m and it says
> > ??? Error using ==> mcc
> > Unable to determine application type, since no wrapper
> > function was specified.
> > Please use the -W switch or specify application type via -m
> > or -l.
> > Type 'mcc -?' for further assistance.
> >
> > The only thing i want to do is exactly what is in the
> > aforementioned "Technical Solution" and that's it!
> >
> > Why the run around?
> >
> >
> >
>
> Hi,
> unfortunately you missed the first line of the solution:
> "Note that compiling M-code to MEX-files is no longer
supported with the
> release of MATLAB Compiler 4.0 (R14)."
> The compile does not convert to C-Code anymore but is more
of a runtime
> environment for the MATLAB code. Therefore converting to a
MEX file would
> not make sense at all, even if the compiler would do it.
>
> Therefore: the profiler is the way to go
> help profile
> and try to speed up the code within MATLAB.
>
> Hope this helps,
> Titus
>
>

No Titus this does not help.

Don't insult me by telling me to use the profiler and that
this doesn't make sense at all!

Im not a novice matlab programmer. I know what i need!

Your response is very similar to other who have asked this
question. (Jim Rockford, 02 march 2008, "Matlab compiler
question")

For years the main feature of the compiler was to convert m
code to mex files. And suddenly without warning it's a "run
time environment". I'v read all the current documentation
and no where does it say the compiler no longer supports mex
file creation!?! This is just crazy!
  

How do i get compiler 3.0 (R13)? I dont care if i have to
go back to R2007a to use it.

"Abel Brown" <brown.2179@osu.edu> wrote in message
news:fstb2b$po6$1@fred.mathworks.com...
> "Titus" <titus.edelhofer@mathworks.de> wrote in message
> <fssq0b$g98$1@fred.mathworks.com>...
>>
>> "Abel Brown" <brown.2179@osu.edu> schrieb im Newsbeitrag
>> news:fsscs7$88n$1@fred.mathworks.com...
>> > OK so im reading "Technical Solutions" with solution ID:
>> > 1-15VWV from February 23 2007 for R2007a.
>> >
>> > The lowdown of tech soln 1-15VWV:
>> > My MEX-file, that was compiled using the MATLAB Compiler 2.1
>> > (R12), runs more slowly than the M-file equivalent. However,
>> > when I use optimizations, I see a significant speed
> improvement.
>> >
>> > For example,
>> >
>> >
>> > tic; squibo(10000); toc
>> >
>> > elapsed_time=
>> > 2.230000
>> >
>> > mcc squibo
>> > tic; squibo(10000); toc;
>> >
>> > elapsed_time=
>> > 5.34000
>> >
>> > mcc -ri squibo
>> > tic; squibo(10000); toc
>> >
>> > elapsed_time=
>> > 0.083400
>> >
>> > I just got my hands on the 2007b matlab compiler desperately
>> > hoping to speed up some interpolation routines etc etc.
>> >
>> > so i call mcc interp_function.m and it says
>> > ??? Error using ==> mcc
>> > Unable to determine application type, since no wrapper
>> > function was specified.
>> > Please use the -W switch or specify application type via -m
>> > or -l.
>> > Type 'mcc -?' for further assistance.
>> >
>> > The only thing i want to do is exactly what is in the
>> > aforementioned "Technical Solution" and that's it!
>> >
>> > Why the run around?
>> >
>> >
>> >
>>
>> Hi,
>> unfortunately you missed the first line of the solution:
>> "Note that compiling M-code to MEX-files is no longer
> supported with the
>> release of MATLAB Compiler 4.0 (R14)."
>> The compile does not convert to C-Code anymore but is more
> of a runtime
>> environment for the MATLAB code. Therefore converting to a
> MEX file would
>> not make sense at all, even if the compiler would do it.
>>
>> Therefore: the profiler is the way to go
>> help profile
>> and try to speed up the code within MATLAB.
>>
>> Hope this helps,
>> Titus
>>
>>
>
> No Titus this does not help.
>
> Don't insult me by telling me to use the profiler and that
> this doesn't make sense at all!

I understand, and I believe Titus understands, that you're trying to create
a MEX-file from an M-file; it's simply not possible with the current version
of MATLAB Compiler.

> Im not a novice matlab programmer. I know what i need!

If there was a new type of file, say a .runfast file, that sped up your code
but was explicitly NOT a MEX-file, would that be acceptable? Is your goal
to have a MEX-file, or is your goal to have your function run faster? [I
suspect the latter.]

If you use the Profiler and MLINT to help you optimize your code and take
advantage of the JIT technology introduced in MATLAB 6.5 (R13) and enhanced
in subsequent releases, the .m file could _be_ that .runfast file.

In case you haven't seen the documentation on the introduction of the JIT
technology (which I think is likely, from the fact that you mentioned you
were using Release 12) here's the link to the release notes on that
technology from Release 13:

http://www.mathworks.com/access/helpdesk_r13/help/base/relnotes/matlab/matlab134.html#52037

You used to accomplish your goal of having your function run faster by
compiling it to a MEX-file. That method is no longer available; now you
will need to try a different approach, namely optimizing your M-file itself,
as Titus suggested.

> Your response is very similar to other who have asked this
> question. (Jim Rockford, 02 march 2008, "Matlab compiler
> question")
>
> For years the main feature of the compiler was to convert m
> code to mex files. And suddenly without warning it's a "run
> time environment".

That change was made in MATLAB Compiler 4.0 (R14), which was released in
mid-2004. This change was not "without warning", but the warnings occurred
several years ago, during one of the releases you "jumped over" in your
conversion from Release 12 to Release R2007b. That's why you were unaware
of this change.

> I'v read all the current documentation
> and no where does it say the compiler no longer supports mex
> file creation!?! This is just crazy!

It was documented in the release notes for MATLAB Compiler 4.0, which are
still included in the release notes for the current version of the Compiler,
version 4.8 (R2008a).

http://www.mathworks.com/access/helpdesk/help/toolbox/compiler/rn/bqnylfk-1.html

> How do i get compiler 3.0 (R13)? I dont care if i have to
> go back to R2007a to use it.

Using that version of the Compiler is not supported with Release R2007a; I
believe you would need to use Release 13 to do so. If you want to do that,
I suggest you contact your sales representative, or the person who maintains
your license.

--
Steve Lord
slord@mathworks.com

"Steven Lord" <slord@mathworks.com> wrote in message
<fstg5b$sm3$1@fred.mathworks.com>...

> I understand, and I believe Titus understands, that
you're trying to create
> a MEX-file from an M-file; it's simply not possible with
the current version
> of MATLAB Compiler.

The very simple reason for that is, contrary to what TMW
tells, ... it's not a compiler

 
> If there was a new type of file, say a .runfast file,
that sped up your code
> but was explicitly NOT a MEX-file, would that be
acceptable? Is your goal
> to have a MEX-file, or is your goal to have your
function run faster? [I suspect the latter.]
 
Apparently the fact one have to install a gigantic 350 Mb
runtime to install a standalone application was considered
completely irrelevant by TMW.

"Pasco Alquim" <pasquimm@yahoo.com> schrieb im Newsbeitrag
news:fstooj$mlf$1@fred.mathworks.com...
> "Steven Lord" <slord@mathworks.com> wrote in message
> <fstg5b$sm3$1@fred.mathworks.com>...
>
>
> The very simple reason for that is, contrary to what TMW
> tells, ... it's not a compiler


The naming has been discussed here quite often.

> Apparently the fact one have to install a gigantic 350 Mb
> runtime to install a standalone application was considered
> completely irrelevant by TMW.

There are pro's and con's for every technical solution. The
size of the MCRInstaller compared to the 8MB installer one
had before may be a con. But for the pro's (or con's for the
"old" compiler, and this list is just from my personal experience:
- the old (R12/R13) compiler had so many restrictions about
what compiled and what did not (e.g. no objects/classes,
therefore making e.g. the database toolbox uncompilable
- many functions in MATLAB were supported by the
compiler, some were not
- when implementing some project in MATLAB you had to
compile sometimes and test, if the code indeed compiles
-in R13 the speed up you gained was already quite low, because
(as Steve mentioned) the gain by JIT was for MATLAB, not
for the compiled code. Now whenever an optimization to
the MATLAB language is added, the compiled code automatically
benefits as well.

Titus

"Abel Brown" <brown.2179@osu.edu> schrieb im Newsbeitrag
news:fstb2b$po6$1@fred.mathworks.com...
> "Titus" <titus.edelhofer@mathworks.de> wrote in message
> <fssq0b$g98$1@fred.mathworks.com>...
>>
>> "Abel Brown" <brown.2179@osu.edu> schrieb im Newsbeitrag
>> news:fsscs7$88n$1@fred.mathworks.com...
>> > OK so im reading "Technical Solutions" with solution ID:
>> > 1-15VWV from February 23 2007 for R2007a.
>> >
>> > The lowdown of tech soln 1-15VWV:
>> > My MEX-file, that was compiled using the MATLAB Compiler 2.1
>> > (R12), runs more slowly than the M-file equivalent. However,
>> > when I use optimizations, I see a significant speed
> improvement.
>> >
>> > For example,
>> >
>> >
>> > tic; squibo(10000); toc
>> >
>> > elapsed_time=
>> > 2.230000
>> >
>> > mcc squibo
>> > tic; squibo(10000); toc;
>> >
>> > elapsed_time=
>> > 5.34000
>> >
>> > mcc -ri squibo
>> > tic; squibo(10000); toc
>> >
>> > elapsed_time=
>> > 0.083400
>> >
>> > I just got my hands on the 2007b matlab compiler desperately
>> > hoping to speed up some interpolation routines etc etc.
>> >
>> > so i call mcc interp_function.m and it says
>> > ??? Error using ==> mcc
>> > Unable to determine application type, since no wrapper
>> > function was specified.
>> > Please use the -W switch or specify application type via -m
>> > or -l.
>> > Type 'mcc -?' for further assistance.
>> >
>> > The only thing i want to do is exactly what is in the
>> > aforementioned "Technical Solution" and that's it!
>> >
>> > Why the run around?
>> >
>> >
>> >
>>
>> Hi,
>> unfortunately you missed the first line of the solution:
>> "Note that compiling M-code to MEX-files is no longer
> supported with the
>> release of MATLAB Compiler 4.0 (R14)."
>> The compile does not convert to C-Code anymore but is more
> of a runtime
>> environment for the MATLAB code. Therefore converting to a
> MEX file would
>> not make sense at all, even if the compiler would do it.
>>
>> Therefore: the profiler is the way to go
>> help profile
>> and try to speed up the code within MATLAB.
>>
>> Hope this helps,
>> Titus
>>
>>
>
> No Titus this does not help.
>
> Don't insult me by telling me to use the profiler and that
> this doesn't make sense at all!
>
> Im not a novice matlab programmer. I know what i need!
>
> Your response is very similar to other who have asked this
> question. (Jim Rockford, 02 march 2008, "Matlab compiler
> question")
>
> For years the main feature of the compiler was to convert m
> code to mex files. And suddenly without warning it's a "run
> time environment". I'v read all the current documentation
> and no where does it say the compiler no longer supports mex
> file creation!?! This is just crazy!
>
>
> How do i get compiler 3.0 (R13)? I dont care if i have to
> go back to R2007a to use it.
>
>
>

I did not want to insult, I just wanted to help.

Titus

"Titus" <titus.edelhofer@mathworks.de> wrote in message
<fsvhhl$ar6$1@fred.mathworks.com>...
>
> "Abel Brown" <brown.2179@osu.edu> schrieb im Newsbeitrag
> news:fstb2b$po6$1@fred.mathworks.com...
> > "Titus" <titus.edelhofer@mathworks.de> wrote in message
> > <fssq0b$g98$1@fred.mathworks.com>...
> >>
> >> "Abel Brown" <brown.2179@osu.edu> schrieb im Newsbeitrag
> >> news:fsscs7$88n$1@fred.mathworks.com...
> >> > OK so im reading "Technical Solutions" with solution ID:
> >> > 1-15VWV from February 23 2007 for R2007a.
> >> >
> >> > The lowdown of tech soln 1-15VWV:
> >> > My MEX-file, that was compiled using the MATLAB
Compiler 2.1
> >> > (R12), runs more slowly than the M-file equivalent.
However,
> >> > when I use optimizations, I see a significant speed
> > improvement.
> >> >
> >> > For example,
> >> >
> >> >
> >> > tic; squibo(10000); toc
> >> >
> >> > elapsed_time=
> >> > 2.230000
> >> >
> >> > mcc squibo
> >> > tic; squibo(10000); toc;
> >> >
> >> > elapsed_time=
> >> > 5.34000
> >> >
> >> > mcc -ri squibo
> >> > tic; squibo(10000); toc
> >> >
> >> > elapsed_time=
> >> > 0.083400
> >> >
> >> > I just got my hands on the 2007b matlab compiler
desperately
> >> > hoping to speed up some interpolation routines etc etc.
> >> >
> >> > so i call mcc interp_function.m and it says
> >> > ??? Error using ==> mcc
> >> > Unable to determine application type, since no wrapper
> >> > function was specified.
> >> > Please use the -W switch or specify application type
via -m
> >> > or -l.
> >> > Type 'mcc -?' for further assistance.
> >> >
> >> > The only thing i want to do is exactly what is in the
> >> > aforementioned "Technical Solution" and that's it!
> >> >
> >> > Why the run around?
> >> >
> >> >
> >> >
> >>
> >> Hi,
> >> unfortunately you missed the first line of the solution:
> >> "Note that compiling M-code to MEX-files is no longer
> > supported with the
> >> release of MATLAB Compiler 4.0 (R14)."
> >> The compile does not convert to C-Code anymore but is more
> > of a runtime
> >> environment for the MATLAB code. Therefore converting to a
> > MEX file would
> >> not make sense at all, even if the compiler would do it.
> >>
> >> Therefore: the profiler is the way to go
> >> help profile
> >> and try to speed up the code within MATLAB.
> >>
> >> Hope this helps,
> >> Titus
> >>
> >>
> >
> > No Titus this does not help.
> >
> > Don't insult me by telling me to use the profiler and that
> > this doesn't make sense at all!
> >
> > Im not a novice matlab programmer. I know what i need!
> >
> > Your response is very similar to other who have asked this
> > question. (Jim Rockford, 02 march 2008, "Matlab compiler
> > question")
> >
> > For years the main feature of the compiler was to convert m
> > code to mex files. And suddenly without warning it's a "run
> > time environment". I'v read all the current documentation
> > and no where does it say the compiler no longer supports mex
> > file creation!?! This is just crazy!
> >
> >
> > How do i get compiler 3.0 (R13)? I dont care if i have to
> > go back to R2007a to use it.
> >
> >
> >
>
> I did not want to insult, I just wanted to help.
>
> Titus
>
>


Look guys

1. it's very sensible for m programmers to want to compile
their code to a mex file for native use within the Matlab
environment.

2. the fact that Mathworks still posts "Technical Solutions"
and loades of documentation for m file compilation years
after the feature has been depreciated would indicate that
it's still a pretty useful and lively feature.

http://www.mathworks.com/support/solutions/data/1-15VWV.html?solution=1-15VWV&BB=1

http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/matlab_external/f29502.html&http://www.mathworks.com/cgi-bin/texis/webinator/search/?db=MSS&prox=page&rorder=750&rprox=750&rdfreq=500&rwfreq=500&rlead=250&sufs=0&order=r&is_summary_on=1&ResultCount=10&query=mex&submitButtonName=Search

3. My code is optimized. There are no mlint msgs and iv
already run the profiler many many times. Im not trying to
use the compiler to speed up junk m file programming. My
interpolation m file takes 44 seconds to execute. The
fortran and C equivalents takes about 2.5 .

4. it is totally worth getting an older version of matlab &
compiler because im not going to spend all day writing
gateway functions etc etc by hand.

 

"Titus" <titus.edelhofer@mathworks.de> wrote in message
<fsvhda$9r6$1@fred.mathworks.com>...
 
> There are pro's and con's for every technical solution.
The
> size of the MCRInstaller compared to the 8MB installer
one
> had before may be a con. But for the pro's (or con's for
the
> "old" compiler, and this list is just from my personal
experience:
> - the old (R12/R13) compiler had so many restrictions
about
> what compiled and what did not (e.g. no objects/classes,
> therefore making e.g. the database toolbox uncompilable
> - many functions in MATLAB were supported by the
> compiler, some were not
> - when implementing some project in MATLAB you had to
> compile sometimes and test, if the code indeed compiles
> -in R13 the speed up you gained was already quite low,
because
> (as Steve mentioned) the gain by JIT was for MATLAB, not
> for the compiled code. Now whenever an optimization to
> the MATLAB language is added, the compiled code
automatically
> benefits as well.
>
> Titus

That is the "official" company response but the fact is
that there was a product which was suddenly abandoned a
replaced another, very different, that took the precedents
name. I don't argue on certain pro's of the run time but
since its another product TWM should not have silently
murdered the true compiler. With all its pro's the run time
is not usable as deploy tool for internet distributed
projects given its huge size (not to mention all the java
shit that comes along).

Pasco

"Abel Brown" <brown.2179@osu.edu> schrieb im Newsbeitrag
news:ft0082$dlm$1@fred.mathworks.com...
> "Titus" <titus.edelhofer@mathworks.de> wrote in message
> <fsvhhl$ar6$1@fred.mathworks.com>...
>>
>> "Abel Brown" <brown.2179@osu.edu> schrieb im Newsbeitrag
>> news:fstb2b$po6$1@fred.mathworks.com...
>> > "Titus" <titus.edelhofer@mathworks.de> wrote in message
>> > <fssq0b$g98$1@fred.mathworks.com>...
>> >>
>> >> "Abel Brown" <brown.2179@osu.edu> schrieb im Newsbeitrag
>> >> news:fsscs7$88n$1@fred.mathworks.com...
>> >> > OK so im reading "Technical Solutions" with solution ID:
>> >> > 1-15VWV from February 23 2007 for R2007a.
>> >> >
>> >> > The lowdown of tech soln 1-15VWV:
>> >> > My MEX-file, that was compiled using the MATLAB
> Compiler 2.1
>> >> > (R12), runs more slowly than the M-file equivalent.
> However,
>> >> > when I use optimizations, I see a significant speed
>> > improvement.
>> >> >
>> >> > For example,
>> >> >
>> >> >
>> >> > tic; squibo(10000); toc
>> >> >
>> >> > elapsed_time=
>> >> > 2.230000
>> >> >
>> >> > mcc squibo
>> >> > tic; squibo(10000); toc;
>> >> >
>> >> > elapsed_time=
>> >> > 5.34000
>> >> >
>> >> > mcc -ri squibo
>> >> > tic; squibo(10000); toc
>> >> >
>> >> > elapsed_time=
>> >> > 0.083400
>> >> >
>> >> > I just got my hands on the 2007b matlab compiler
> desperately
>> >> > hoping to speed up some interpolation routines etc etc.
>> >> >
>> >> > so i call mcc interp_function.m and it says
>> >> > ??? Error using ==> mcc
>> >> > Unable to determine application type, since no wrapper
>> >> > function was specified.
>> >> > Please use the -W switch or specify application type
> via -m
>> >> > or -l.
>> >> > Type 'mcc -?' for further assistance.
>> >> >
>> >> > The only thing i want to do is exactly what is in the
>> >> > aforementioned "Technical Solution" and that's it!
>> >> >
>> >> > Why the run around?
>> >> >
>> >> >
>> >> >
>> >>
>> >> Hi,
>> >> unfortunately you missed the first line of the solution:
>> >> "Note that compiling M-code to MEX-files is no longer
>> > supported with the
>> >> release of MATLAB Compiler 4.0 (R14)."
>> >> The compile does not convert to C-Code anymore but is more
>> > of a runtime
>> >> environment for the MATLAB code. Therefore converting to a
>> > MEX file would
>> >> not make sense at all, even if the compiler would do it.
>> >>
>> >> Therefore: the profiler is the way to go
>> >> help profile
>> >> and try to speed up the code within MATLAB.
>> >>
>> >> Hope this helps,
>> >> Titus
>> >>
>> >>
>> >
>> > No Titus this does not help.
>> >
>> > Don't insult me by telling me to use the profiler and that
>> > this doesn't make sense at all!
>> >
>> > Im not a novice matlab programmer. I know what i need!
>> >
>> > Your response is very similar to other who have asked this
>> > question. (Jim Rockford, 02 march 2008, "Matlab compiler
>> > question")
>> >
>> > For years the main feature of the compiler was to convert m
>> > code to mex files. And suddenly without warning it's a "run
>> > time environment". I'v read all the current documentation
>> > and no where does it say the compiler no longer supports mex
>> > file creation!?! This is just crazy!
>> >
>> >
>> > How do i get compiler 3.0 (R13)? I dont care if i have to
>> > go back to R2007a to use it.
>> >
>> >
>> >
>>
>> I did not want to insult, I just wanted to help.
>>
>> Titus
>>
>>
>
>
> Look guys
>
> 1. it's very sensible for m programmers to want to compile
> their code to a mex file for native use within the Matlab
> environment.
>
> 2. the fact that Mathworks still posts "Technical Solutions"
> and loades of documentation for m file compilation years
> after the feature has been depreciated would indicate that
> it's still a pretty useful and lively feature.
>
> http://www.mathworks.com/support/solutions/data/1-15VWV.html?solution=1-15VWV&BB=1
>
> http://www.mathworks.com/access/helpdesk/help/techdoc/index.html?/access/helpdesk/help/techdoc/matlab_external/f29502.html&http://www.mathworks.com/cgi-bin/texis/webinator/search/?db=MSS&prox=page&rorder=750&rprox=750&rdfreq=500&rwfreq=500&rlead=250&sufs=0&order=r&is_summary_on=1&ResultCount=10&query=mex&submitButtonName=Search
>
> 3. My code is optimized. There are no mlint msgs and iv
> already run the profiler many many times. Im not trying to
> use the compiler to speed up junk m file programming. My
> interpolation m file takes 44 seconds to execute. The
> fortran and C equivalents takes about 2.5 .
>
> 4. it is totally worth getting an older version of matlab &
> compiler because im not going to spend all day writing
> gateway functions etc etc by hand.
>
>

Hi,
some comments:
1. the reason for doing this? Speed? Steve already covered this...
2.
  the first link is for people using the old version (yes, there probably
still are some) ;-)
  the second one is about mex files (with NO relation at all to the old or
new compiler)
3. Sorry, if you thought that my original posting looked as if I thought bad
about your coding. Probably the fact, that you use MATLAB since R12 should
have told me, that you indeed know what you are doing. Sorry again.
just for curiosity: what are the timings for your code in
   ML R12
   ML R12, compiled with compiler
   ML R13
   ML R13, compiled with compiler
   ML R14 or newer
4. again: Steve already mentioned what to do ...

Titus

"Pasco Alquim" <pasquimm@yahoo.com> schrieb im Newsbeitrag
news:ft01dj$qhk$1@fred.mathworks.com...
> "Titus" <titus.edelhofer@mathworks.de> wrote in message
> <fsvhda$9r6$1@fred.mathworks.com>...
>
>> There are pro's and con's for every technical solution.
> The
>> size of the MCRInstaller compared to the 8MB installer
> one
>> had before may be a con. But for the pro's (or con's for
> the
>> "old" compiler, and this list is just from my personal
> experience:
>> - the old (R12/R13) compiler had so many restrictions
> about
>> what compiled and what did not (e.g. no objects/classes,
>> therefore making e.g. the database toolbox uncompilable
>> - many functions in MATLAB were supported by the
>> compiler, some were not
>> - when implementing some project in MATLAB you had to
>> compile sometimes and test, if the code indeed compiles
>> -in R13 the speed up you gained was already quite low,
> because
>> (as Steve mentioned) the gain by JIT was for MATLAB, not
>> for the compiled code. Now whenever an optimization to
>> the MATLAB language is added, the compiled code
> automatically
>> benefits as well.
>>
>> Titus
>
> That is the "official" company response but the fact is
> that there was a product which was suddenly abandoned a
> replaced another, very different, that took the precedents
> name. I don't argue on certain pro's of the run time but
> since its another product TWM should not have silently
> murdered the true compiler. With all its pro's the run time
> is not usable as deploy tool for internet distributed
> projects given its huge size (not to mention all the java
> shit that comes along).
>
> Pasco

Although I do work for The MathWorks, this was my personal
opinion (and I do work a lot with the compiler, since R12.0),
and not an official statement.
If or if not it was a good decision to keep the name, although
the underlying product changed it's technical basis is a question
I can not answer.
For the size: the MCR of 175MB needs to be downloaded by
the end user only once, the compiled application typically is
small.

Titus

"Titus" <titus.edelhofer@mathworks.de> wrote in message
<ft0oql$eb2$1@fred.mathworks.com>...
 
> Although I do work for The MathWorks, this was my personal
> opinion (and I do work a lot with the compiler, since
R12.0),
> and not an official statement.
> If or if not it was a good decision to keep the name,
although
> the underlying product changed it's technical basis is a
question
> I can not answer.
> For the size: the MCR of 175MB needs to be downloaded by
> the end user only once, the compiled application
typically is small.

Ok, the ~350 Mb is after installing.
But I can't resist another question. If compiling m code
brings no speed advantage why the Embedded Toolbox
www.mathworks.com/products/featured/embeddedmatlab/
index.html?BB=1

says:

"By employing the Embedded MATLAB language subset, you can
automatically generate C code directly from MATLAB code,
for the first time gaining a direct path to embedded
software implementation from MATLAB. With MATLAB code
written using the Embedded MATLAB subset, you can:
 
o - Use MATLAB and Fixed Point Toolbox to develop
embeddable floating-point and fixed-point code and run
simulations at compiled C speed"

Pasco

"Pasco Alquim" <pasquimm@yahoo.com> schrieb im Newsbeitrag
news:ft2n4p$70n$1@fred.mathworks.com...
> "Titus" <titus.edelhofer@mathworks.de> wrote in message
> <ft0oql$eb2$1@fred.mathworks.com>...
>
>> Although I do work for The MathWorks, this was my personal
>> opinion (and I do work a lot with the compiler, since
> R12.0),
>> and not an official statement.
>> If or if not it was a good decision to keep the name,
> although
>> the underlying product changed it's technical basis is a
> question
>> I can not answer.
>> For the size: the MCR of 175MB needs to be downloaded by
>> the end user only once, the compiled application
> typically is small.
>
> Ok, the ~350 Mb is after installing.
> But I can't resist another question. If compiling m code
> brings no speed advantage why the Embedded Toolbox
> www.mathworks.com/products/featured/embeddedmatlab/
> index.html?BB=1
>
> says:
>
> "By employing the Embedded MATLAB language subset, you can
> automatically generate C code directly from MATLAB code,
> for the first time gaining a direct path to embedded
> software implementation from MATLAB. With MATLAB code
> written using the Embedded MATLAB subset, you can:
>
> o - Use MATLAB and Fixed Point Toolbox to develop
> embeddable floating-point and fixed-point code and run
> simulations at compiled C speed"
>
> Pasco

Hi Pasco,
the target for the Embedded Toolbox is somewhat different:
the Embedded Toolbox aims at (guess? ;-)) embedded targets
where MATLAB doesn't run. The MATLAB compiler needs
a system where the MCR runs, i.e., the compiled program runs
only on the platforms supported by MATLAB (BTW a restriction
the old compiler had of course as well.
The Embedded MATLAB translates the code to pure C-code
(no reliance on precompiled libraries/run-time environmet) so
you can port the code to (of course more or less) any target
with a decent C-compiler.

Titus