Home > Archive > Matlab > August 2007 > a standalone application from matlab compiler?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
a standalone application from matlab compiler?
|
|
|
| Hi Everyone:
I recently used the Matlab compiler to generate a standalone
exe file. The dataset is large and Matlab can not read in
the large dataset. Therefore I use the Matlab compiler to
create a standalone .exe file. Use the .exe file, I can read
in the dataset but at some step in processing the dataset,
the program is broken saying that "Out of memory" and
"MATLAB:nomem". I am quite  . The standalone .exe
file, as the name implies, should not rely on the Matlab
when running and thus I donot understand why the problem is
Matlab related. Could someone give me some advice on why is
this and what I can do to prevent "out of memory" problem
with standalone application? Many thanks. I have enclosed my
code and error message as below:
function main
load('D:\purch.dat');
t2=clock;
pmean=mean(purch)
t3=clock;
tmean=etime(t3,t2)
psize=size(purch(:,2:16))
After I used mcc to compile the M file to a .exe file and
run the .exe file under the DOS command Prompt, I got the
following message:
tmean=
187.1410
??? Out of memory. Type HELP MEMORY for your options
Error in ==> wm at 9
(I note: the 9th line is psize=size(purch(:,2:16))
MATLAB:nomem
| |
| Walter Roberson 2007-08-28, 6:14 am |
| In article <fb029m$pe3$1@fred.mathworks.com>,
HIu <sealights30@yahoo.com> wrote:
>I recently used the Matlab compiler to generate a standalone
>exe file. The dataset is large and Matlab can not read in
>the large dataset. Therefore I use the Matlab compiler to
>create a standalone .exe file. Use the .exe file, I can read
>in the dataset but at some step in processing the dataset,
>the program is broken saying that "Out of memory" and
>"MATLAB:nomem". I am quite . The standalone .exe
>file, as the name implies, should not rely on the Matlab
>when running and thus I donot understand why the problem is
>Matlab related.
>function main
>
>load('D:\purch.dat');
>t2=clock;
>pmean=mean(purch)
>t3=clock;
>tmean=etime(t3,t2)
>psize=size(purch(:,2:16))
When matlab produces an executable, it does not compile in
the code for each of the matlab functions you use (or
which those functions call upon to do portions of the work).
Instead, matlab uses a fixed shared library (.dll in Windows terms)
which contains all of the core matlab routines, and the
compiled executable calls into the shared library at need.
>After I used mcc to compile the M file to a .exe file and
>run the .exe file under the DOS command Prompt, I got the
>following message:
>tmean=
> 187.1410
>??? Out of memory. Type HELP MEMORY for your options
>Error in ==> wm at 9
>(I note: the 9th line is psize=size(purch(:,2:16))
>MATLAB:nomem
If memory is short, why would you take a size like that???
size(purch(:,2:16)) is going to be the same as
[size(purch,1), size(2:16,2)] which is going to be the same as
[size(purch,1), 15].
When you do it the way you have coded, Matlab has to take a copy
columns 2 thru 16 of all of the rows of purch, and then run the
size() operator on the result (and then throws away the temporary copy.)
If you code it the way I show, as [size(purch,1), size(2:16,2)]
or [size(purch,1), 15] then Matlab will not need to take a copy
of the data at all, and the statement will not run out of memory.
With that change, you probably wouldn't even run out of memory
in a plain .m file (unless later code chews up memory.)
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes
| |
|
| Many thanks, Walter. I understand more about Matlab compiler
now from you comments. I know the way I used the command
"size" is far from ideal, but I just like to try if a bit of
manipulation with large dataset would work. If the command
"size" won't work, then I would expect some other more
intensive commands on a subset of data will broke down. For
example, what if I want to calculate matrix product of the
subsets of two large matrix?
roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
message <fb0amj$sv7$1@canopus.cc.umanitoba.ca>...
> In article <fb029m$pe3$1@fred.mathworks.com>,
> HIu <sealights30@yahoo.com> wrote:
>
>
>
>
> When matlab produces an executable, it does not compile in
> the code for each of the matlab functions you use (or
> which those functions call upon to do portions of the work).
> Instead, matlab uses a fixed shared library (.dll in
Windows terms)
> which contains all of the core matlab routines, and the
> compiled executable calls into the shared library at need.
>
>
>
>
> If memory is short, why would you take a size like that???
> size(purch(:,2:16)) is going to be the same as
> [size(purch,1), size(2:16,2)] which is going to be the same as
> [size(purch,1), 15].
>
> When you do it the way you have coded, Matlab has to take
a copy
> columns 2 thru 16 of all of the rows of purch, and then
run the
> size() operator on the result (and then throws away the
temporary copy.)
> If you code it the way I show, as [size(purch,1),
size(2:16,2)]
> or [size(purch,1), 15] then Matlab will not need to take a
copy
> of the data at all, and the statement will not run out of
memory.
>
> With that change, you probably wouldn't even run out of memory
> in a plain .m file (unless later code chews up memory.)
> --
> Is there any thing whereof it may be said, See, this is
new? It hath
> been already of old time, which was before us. --
Ecclesiastes
| |
| Walter Roberson 2007-08-30, 4:29 am |
| In article <fb5ak1$qph$1@fred.mathworks.com>,
HIu <sealights30@yahoo.com> wrote:
>I know the way I used the command
>"size" is far from ideal, but I just like to try if a bit of
>manipulation with large dataset would work. If the command
>"size" won't work, then I would expect some other more
>intensive commands on a subset of data will broke down. For
>example, what if I want to calculate matrix product of the
>subsets of two large matrix?
Then you'll run out of memory.
If you need to work with large arrays, and they aren't sparse
arrays, then you may need to use loops instead of vectorizing,
and you may need to use "blocking" techniques. For matrix
multiplication A * B, if you don't have enough memory for
(size(A,1) * size(B,2)) elements of results (and it isn't a
sparse calculation), then you just cannot do it -- the result
has to go -somewhere-. Unless you use intermediate files or
something like that to store the results.
I gather that the 3rd party matrix library that Matlab uses has
(in general) routines that do the work by "blocking"; I don't know
if those routines are available via Matlab.
But these days, the cheapest way to deal with this sort of
problem is to upgrade to a computer with 64 bit support
and use the 64 bit version of Matlab. If you consider the
cost of the computer with more memory, and compare that to
the cost of having you write and thoroughly debug the routines
that go through a lot of trouble to manipulate large arrays with
little spare space, then unless you are being paid very little
(and have lots of spare time) or unless taxes on computers are
really high, then the write-it-yourself approach is seldom
cost effective.
--
Programming is what happens while you're busy making other plans.
| |
|
| I agree with you that with large dataset, a 64-bit computer
is the go, in order to save all those hassles. Many thanks!
roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) wrote in
message <fb0amj$sv7$1@canopus.cc.umanitoba.ca>...
> In article <fb029m$pe3$1@fred.mathworks.com>,
> HIu <sealights30@yahoo.com> wrote:
>
>
>
>
> When matlab produces an executable, it does not compile in
> the code for each of the matlab functions you use (or
> which those functions call upon to do portions of the work).
> Instead, matlab uses a fixed shared library (.dll in
Windows terms)
> which contains all of the core matlab routines, and the
> compiled executable calls into the shared library at need.
>
>
>
>
> If memory is short, why would you take a size like that???
> size(purch(:,2:16)) is going to be the same as
> [size(purch,1), size(2:16,2)] which is going to be the same as
> [size(purch,1), 15].
>
> When you do it the way you have coded, Matlab has to take
a copy
> columns 2 thru 16 of all of the rows of purch, and then
run the
> size() operator on the result (and then throws away the
temporary copy.)
> If you code it the way I show, as [size(purch,1),
size(2:16,2)]
> or [size(purch,1), 15] then Matlab will not need to take a
copy
> of the data at all, and the statement will not run out of
memory.
>
> With that change, you probably wouldn't even run out of memory
> in a plain .m file (unless later code chews up memory.)
> --
> Is there any thing whereof it may be said, See, this is
new? It hath
> been already of old time, which was before us. --
Ecclesiastes
|
|
|
|
|