is a for-loor really going to take that long?
Samuel H?gglund
I run two almost identical for loops with the difference that one
inserts a value into a matrix and the other inserts a value into a
variable. Is it true that a loop containing a matrix takes 4 times
longer than a loop with a variable? Four times seems a little bit too
much in my opinion.
Thx,
Rgds /S
MATLAB Version 6.5.1.199709 (R13) Service Pack 1, on Win XP
---------------------
>> tic;for a=1:1:10100101 b=10000;end, toc
elapsed_time =
3.5320
------------------------
>> tic,b=zeros(1,2);for a=1:1:10100101 b(1,2)=1;end, toc
elapsed_time =
12.3280
---------------------
zboot
implements this line:
b(1,1) = 100; versus b = 100;
b(1,1) - means you are indexing an array, therefore, calculations
must be done on a pointer to determine where you want to goto. Now,
you may say, well, matlab should be smart enough to realize that I'm
accessing the same memory location. Well. . maybe not.
with b = 100, you're just writing data directly to memory, skipping
pointer arithmetric and/or whatever function and code matlab calls to
do that. . .so thats probably whats eating your time
per isakson
Explain this one!
>> cssm
ans =
9.8740 0.2500 0.3910 9.9200
function M = cssm( N )
tic
b=zeros(1,1);
for a=1:1:10100101
b=1;
end,
t0 = toc; tic
b=zeros(1,1);
for a=1:1:10100101
b(1,1)=1;
end,
t1 = toc; tic
b=zeros(1,2);
for a=1:1:10100101
b(1,2)=1;
end
t2 = toc; tic;
for a=1:1:10100101
b=10000;
end,
t3=toc;
M = [ t0, t1, t2, t3 ];
return
>> ver
----------------------------------------
MATLAB Version 6.5.0.180913a (R13)
Operating System: Microsoft Windows 2000 Version 5.0 (Build 2195:
Service Pack 4)
Samuel H?gglund
Using your code,inserting values into a matrix is quicker than
inserting into a variable.
I can imagine that the matrix has a pre-defined memory space with
direct access and the variable has to create new space all the time.
That would make the matrix quicker but still, that doesn't explain the
difference in the result of our code.
Why do the results contradict each other? Why is it like that?
/S
"per isakson" <po...@bim1.kth4.se> wrote in message news:<eef2...@webx.raydaftYaTP>...
Rune Allnor
> Dear all,
>
> I run two almost identical for loops with the difference that one
> inserts a value into a matrix and the other inserts a value into a
> variable. Is it true that a loop containing a matrix takes 4 times
> longer than a loop with a variable? Four times seems a little bit too
> much in my opinion.
Well, when you use matlab you pay to minimize your own time writing
code. The price is paid in terms of computer run-time. Or by spending
time working around matlab-specific quirks by trying to "vectorize"
your code. Try to run this script:
% ================= Script looptest.m ============================
% Rune Allnor 2004/11/16
% Posted at comp.soft-sys.matlab
N=10000000; % Reduce if memory expires
V=0:N-1;
sum1=0;
sw1=cputime;
for n=1:N
sum1=sum1+V(n);
end
cputime1=cputime-sw1;
sw2=cputime;
sum2=sum(V);
cputime2=cputime-sw2;
disp(['Run-time, computing the sum of ',int2str(N),' elements:']);
disp(['For-loop : ',num2str(cputime1),' seconds']);
disp(['Built-in function : ',num2str(cputime2),' seconds']);
% ==== End looptest.m ============================================
The output on my computer is
Run-time, computing the sum of 10000000 elements:
For-loop : 36.437 seconds
Built-in function : 0.203 seconds
which means there is an overhead factor of 36.4/0.2 = 180 when matlab
implements a for-loop. My comuter runs at 1.4 GHz, which in turn, mean
that the for-loop runs at an effective frequency of 1400 MHz /180 =
7.5 MHz. Just for comparision, the last time I worked with a 7.5 MHz
computer was 1988.
Rune
Titus Edelhofer
what version of MATLAB are you using? I ran your code
on R14 and got the following timing (1.2GHz):
Run-time, computing the sum of 10000000 elements:
For-loop : 0.23033 seconds
Built-in function : 0.11016 seconds
Titus
"Rune Allnor" <all...@tele.ntnu.no> wrote in message
news:f56893ae.04111...@posting.google.com...
andrea
>
>
> Hi Rune,
> what version of MATLAB are you using? I ran your code
> on R14 and got the following timing (1.2GHz):
>
> Run-time, computing the sum of 10000000 elements:
> For-loop : 0.23033 seconds
> Built-in function : 0.11016 seconds
>
on an IBM server with 4 processor intel xeon 3.2 ghz and 6GB RAM and
Matlab 7.0.1 I get
Run-time, computing the sum of 10000000 elements:
For-loop : 0.452 seconds
Built-in function : 0.263 seconds
on an AMD Athlon 1900, 512 mb ram and matlab6.5 I get
Run-time, computing the sum of 10000000 elements:
For-loop : 0.234 seconds
Built-in function : 0.093 seconds
why the more powerful hardware takes so much??
zboot
here we go: from function cssm
The first loop:
- you also loose some time as this is when a is first created, since
you don't change the type, you don't loose this time throughout.
b - initialized as an array of zeros, then, you kill the array and
set b = 1 inside the loop. You loose lots of time killing b as an
array then using it as a scalar.
The Second Loop
- apparently, killing a scalar is faster than killing an array
The Third Loop
This one takes longer mainly cuz your array is longer. . otherwise,
it would be pretty much the same speed as the second.
The Fourth Loop
- to tell the truth, this one is a little insteresting. . i'm
guessing there is different storage for the numbers 1 and 10,000 . .
other than that, I don't see why the speed would be comparable to the
first.
Stuart McGarrity
but certain optimizations can only be done in function files. The command
line is not JITed at all.
Also don't switch between using a variable as an array (b=zeros(1,1)) then a
scalar (b=1), especially in a tight loop. Copying between then can require
convertion/temporay storage taking time.
Stuart
"Samuel H?gglund" <kku...@hotmail.com> wrote in message
news:96ec3ac4.04111...@posting.google.com...
Rune Allnor
> Hi Rune,
> what version of MATLAB are you using?
I'm running v 6.5.1.
Rune
Titus Edelhofer
very strange, with 6.5.1 I get still times of about the same magnitude:
Run-time, computing the sum of 10000000 elements:
For-loop : 0.261 seconds
Built-in function : 0.09 seconds
Titus
"Rune Allnor" <all...@tele.ntnu.no> wrote in message
news:f56893ae.04111...@posting.google.com...
Brett Shoelson
As Stuart pointed out, this is likely the result of JITing or not JITing. In
a script file, or from the command line:
M =
4.1390 12.9850 13.0990 4.2360
In a (JITed) mfile:
M =
7.2880 0.3900 0.4060 7.3040
(R14SP1)
Cheers,
Brett
Samuel H?gglund
> If you want things to go fast, put them in function files. Scripts are JITed
> but certain optimizations can only be done in function files. The command
> line is not JITed at all.
>
> Also don't switch between using a variable as an array (b=zeros(1,1)) then a
> scalar (b=1), especially in a tight loop. Copying between then can require
> convertion/temporay storage taking time.
>
> Stuart
The thing is,I don't switch between a scalar and an array. In one
loop, "test1" I _only_ use a scalar.I don't switch between matrix and
scalars within a loop. I only use the same type.
In an earlier posting someone got a contradictory result compared to
mine; inserting values into a matrix vas faster than inserting to a
scalar. "test2" was faster than "test1" which doesn't make sense. Why
is that? Why are the results different and why is one method faster
than the other?
/S
Using functions I get the following results (still, one is faster than
the other):
>> test1
elapsed_time =
0.0470
--------------
>> test2
elapsed_time =
0.1870
-----------------
function a=test1()
tic;for a=1:1:10100101 b=10000;end, toc
------------------------
function a=test2()
Rune Allnor
"JITing" might very well have something to do with it. I haven't done
anything to "JIT" my m-files. In fact, I only have a very vague
impression of what "JIT" is and what it does...
Apropos mentioning what I did in 1988 in an earlier post, I can't help
thinking that all this stuff about "vectorizing" and "JIT" reminds me
of the 640k primary memory model (which was divided into 64k memory
pages) that was still in effect on the PC with MS-DOS in 1988. I had
this (at the time) huge computer with 2 MB RAM, that I just was not
able to use properly because of these artificial limitations imposed
on me by the OS. As long as I worked within the 64k page, everything
was fine. Once I needed more than 64k of memory, all hell broke loose.
The MS-DOS memory model was the one single reason why I first of all
abandoned a carreer in computer science (I saw no point in spending 99%
of my time on dealing with memory mapping models that just ought not
to be needed), and second spent the next decade with UNIX.
I can see the same tendency now with matlab. Most of my time is spent on
formulating the problems in all sorts of weird ways that really have
nothing to do with the algorithms themselves, but more with getting
matlab to run at a decent speed. The limitations and quirks that are
caused by the particular ways matlab do things, start to become so
troublesome and annoying that I wonder whether using matlab is worth
the effort. Which is a shame, really.
Rune
Bob Gilmore
kku...@hotmail.com (Samuel H?gglund) wrote:
<message from Stuart snipped>
> The thing is,I don't switch between a scalar and an array. In one
> loop, "test1" I _only_ use a scalar.I don't switch between matrix and
> scalars within a loop. I only use the same type.
>
> In an earlier posting someone got a contradictory result compared to
> mine; inserting values into a matrix vas faster than inserting to a
> scalar. "test2" was faster than "test1" which doesn't make sense. Why
> is that? Why are the results different and why is one method faster
> than the other?
>
> /S
> Using functions I get the following results (still, one is faster than
> the other):
> >> test1
>
> elapsed_time =
>
> 0.0470
> --------------
> >> test2
>
> elapsed_time =
>
> 0.1870
> -----------------
> function a=test1()
> tic;for a=1:1:10100101 b=10000;end, toc
> ------------------------
> function a=test2()
> tic,b=zeros(1,2);for a=1:1:10100101 b(1,2)=1;end, toc
Keep in mind that, even though it's not obvious from this example,
MATLAB has to do many more checks in test2 as opposed to test1.
In test1, MATLAB can just create an mxArray pointing to the double value
1, and make b a pointer to that mxArray.
But in test2, MATLAB has to ask...
(1) What type is b? Because...
(1a) If it isn't double, then I'll have to cast that "1" to the
appropriate type.
(1b) If it isn't numeric (or char, or logical), then I'll have to see if
I can convert that "1" to the appropriate class. If not, then I'll
probably error. (That piece is actually handled by dispatching to the
appropriate SUBSASGN method when necessary).
(2) Is b complex? Because if it isn't, I'll have to allocate more
memory to store the zero imaginary part.
(3) Is b sparse? If so, I'll have to deal with memory differently.
(4) Does the referenced element already exist, or does this assignment
force the array to grow dynamically? (The price you pay for automatic
bounds checking and array growth).
Now, all of these checks are answered in the "fast" way in this case;
everything's double, nothing's complex, and so on. But those questions
DO have to be asked. I suspect that those checks account for a lot of
the slowdown in your test2 vs. your test1.
--
Bob Gilmore, Software Engineer,
The MathWorks, Inc.
per isakson
>
>
<snip>
>> In an earlier posting someone got a contradictory
>> result compared to mine; inserting values
>> into a matrix vas faster than inserting >> to a scalar.
"test2" was faster than >> "test1" which doesn't make sense.
The reason for this strange result was that I did reuse the variable,
b, without paying appropriate attention to its type. I have redone
the tests with "clear b" before each test. Result: assigning to an
array takes five times as long as assigning to a scalar. See below.
<snip>
<snip>
> --
> Bob Gilmore, Software Engineer,
> The MathWorks, Inc.
>
Thanks Bob for shedding some light over our test results.
The function cssm (see below) gives the following result:
0.2500 0.3910 0.4220 0.3590 0.0620 0.0470 10.0000
0.2500 0.3900 0.4220 0.3600 0.0780 0.0470 9.8430
0.2500 0.3910 0.4220 0.3590 0.0630 0.0620 9.9380
Assigning to an array of double takes five times as much cpu-time as
assigning to a scalar.
In my last test assigning takes 150 times as much cpu-time as
assigning to a scalar. That's obvious because of (1a), but I'm
surprised the effect is so large. I'll be a bit more careful with my
temporary variables.
I'm on
MATLAB Version 6.5.0.180913a (R13)
OS: Microsoft Windows 2000, SP4
/ per
function M = cssm
clear( 'b' ), t1 = cputime;
b=zeros(1,1);
for a=1:1:10100101
b(1,1)=1;
end,
t1 = cputime - t1;
clear( 'b' ), t2 = cputime;
b=zeros(1,2);
for a=1:1:10100101
b(1,2)=1;
end
t2 = cputime - t2;
clear( 'b' ), t3 = cputime;
b=zeros(1000);
for a=1:1:10100101
b(1,2)=1;
end
t3 = cputime - t3;
clear( 'b' ), t4 = cputime;
b=zeros(1000);
for a=1:1:10100101
b(1,2)=1000000000000001.12;
end
t4 = cputime - t4;
clear( 'b' ), t5 = cputime;
for a=1:1:10100101
b=1;
end,
t5=cputime - t5;
clear( 'b' ), t6 = cputime;
for a=1:1:10100101
b=1000000000000001.12;
end,
t6=cputime - t6;
clear( 'b' ), t7 = cputime;
b=zeros(1,1);
for a=1:1:10100101
b=1;
end,
t7 = cputime - t7;
M = [ t1, t2, t3, t4, t5, t6, t7 ];
return
Yi Cao
Run the same code I got:
0.3750 0.3906 0.4063 0.3438 0.0625 0.0625 6.6719
That is fine since t7 corresponds to mixing b between array and
double.
However, if I change the line before the lase for-loop
(b=zeros(1,1);) to: b(1,1)=0; then I got the following results:
0.3594 0.3906 0.4063 0.3594 6.6563 6.7500 6.7969
That means change code within t7 also slow down speed at t6 and t5. I
guess these is because of JIT optimization. It tries to look overall
code to determine the "best" way to speed up calculation. But, it
makes performance worse.
per isakson
>
>
<snip>
> With MATLAB R14SP1 I get very strange results:
>
> Run the same code I got:
> 0.3750 0.3906 0.4063 0.3438 0.0625 0.0625 6.6719
>
> That is fine since t7 corresponds to mixing b between array and
> double.
>
> However, if I change the line before the lase for-loop
> (b=zeros(1,1);) to: b(1,1)=0; then I got the following results:
> 0.3594 0.3906 0.4063 0.3594 6.6563 6.7500 6.7969
>
> That means change code within t7 also slow down speed at t6 and t5.
> I
> guess these is because of JIT optimization. It tries to look
> overall
> code to determine the "best" way to speed up calculation. But, it
> makes performance worse.
Strange! What does the M-Lint Code Checker say about this? (I still
run R13.)
/ per
Yi Cao
The value assigned here to variable 'b' is never used
Ryan J Ollos
> With MATLAB R14SP1 I get very strange results:
>
> Run the same code I got:
> 0.3750 0.3906 0.4063 0.3438 0.0625 0.0625 6.6719
>
> That is fine since t7 corresponds to mixing b between array and
> double.
>
> However, if I change the line before the lase for-loop
> (b=zeros(1,1);) to: b(1,1)=0; then I got the following results:
> 0.3594 0.3906 0.4063 0.3594 6.6563 6.7500 6.7969
>
> That means change code within t7 also slow down speed at t6 and t5.
> I
> guess these is because of JIT optimization. It tries to look
> overall
> code to determine the "best" way to speed up calculation. But, it
> makes performance worse.
I get results that agree with yours. Before making the change:
0.3750 0.3590 0.3750 0.3750 0.0630 3.0470 6.0310
After making the change:
0.3750 0.3590 0.3910 0.4060 5.9530 5.9060 5.9690
Interesting though that t6 is already slower for me before making the
change.
I have:
--------------------------------------------
MATLAB Version 7.0.0.19920 (R14)
MATLAB License Number: 164896
Operating System: Microsoft Windows XP Version 5.1 (Build 2600:
Service Pack 2)
Java VM Version: Java 1.4.2 with Sun Microsystems Inc. Java
HotSpot(TM) Client VM
--------------------------------------------
It would be nice to have an explanation for all of this, but as Rune
mentioned earlier, we are digging into a level of complexity in
matlab that is sort of destroying the purpose of matlab, which is to
make life easier for us by hiding the details of how memory is
allocated and such. I can handle following some rules, such as
vectorization and allocating variables appropriately, but if the
above differences are due to the way matlab optimizes code, then i
think the fault lies with an undesireable effect of the run-time
engine or compiler or whatever you call it.
serkan
have so
much debt around.My father died 1 year a go and now i m alone with my
mother.We even do not have any thing to eat at the moment.Y m writing
this
message from a cafe with my last money.The owner of the house we live
shoot us from the house because we could not pay the rents.NOW i
intended to sell one of my KIDNEYs.I m 30 years old and my blood type
is '0' RH -.I m very healthy and i can give my kidney when ever you
want but you have to come to Turkey for the transplantation.I m
offering 150.000 EURO.I ll pay much of this money for our debts and
rest for eating something up to the time i ll find a job.Thanks for
your helps from now.Have nice and healthy days.
phone:0090 538 403 50 30