Thread Subject: matlab 7.1 faster than 7.6 !

Hi all,

I've run a pretty demanding program in both matlab 7.1 and 7.6 on the exakt same computer. What takes 4.3 seconds in 7.1 takes 11.5 seconds in 7.6! How is this possible? Is matlab getting slower for each release, or when did this happen??

Hope you can inform me

Best

PS. Oh, and since 7.1 doesn't run on Vista, and I thus have to use 7.6, this means that my new state of the art laptop runs equally fast as my three years old shitty HP. This sucks.

"Pontus " <pontus.rendahl@gmail.com> wrote in message <gd07t7$6nq$1@fred.mathworks.com>...
> Hi all,
>
> I've run a pretty demanding program in both matlab 7.1 and 7.6 on the exakt same computer. What takes 4.3 seconds in 7.1 takes 11.5 seconds in 7.6! How is this possible? Is matlab getting slower for each release, or when did this happen??
>

What you describe is not normal. In my experience in general Matlab gets faster because its Math library (Blas) get better, and the enhancement is quite noticeable.

May be your program starts to run out of memory and with it swaps on the HD with the new version.

Use profiler tool to locate the place of your program where it gets slower.

Bruno

Hi Bruno,

Thanks for your reply. The facts, however, remain: Running the SAME program on the SAME computer yields different CPU times for different versions of MATLAB. The older version is MUCH faster.

Anyone?

Pontus

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <gd08e2$bch$1@fred.mathworks.com>...
> "Pontus " <pontus.rendahl@gmail.com> wrote in message <gd07t7$6nq$1@fred.mathworks.com>...
> > Hi all,
> >
> > I've run a pretty demanding program in both matlab 7.1 and 7.6 on the exakt same computer. What takes 4.3 seconds in 7.1 takes 11.5 seconds in 7.6! How is this possible? Is matlab getting slower for each release, or when did this happen??
> >
>
> What you describe is not normal. In my experience in general Matlab gets faster because its Math library (Blas) get better, and the enhancement is quite noticeable.
>
> May be your program starts to run out of memory and with it swaps on the HD with the new version.
>
> Use profiler tool to locate the place of your program where it gets slower.
>
> Bruno

"Pontus " <pontus.rendahl@gmail.com> wrote in message
news:gd0c0g$gvd$1@fred.mathworks.com...
> Hi Bruno,
>
> Thanks for your reply. The facts, however, remain: Running the SAME
> program on the SAME computer yields different CPU times for different
> versions of MATLAB. The older version is MUCH faster.
>
> Anyone?

Without being able to see the code (or at the VERY least seeing the Profiler
report created from running the code in the MATLAB Profiler) any explanation
or suggestions as to why you're seeing what you're seeing would be no better
than a guess or a shot in the dark. Therefore I recommend you send your
code to Technical Support for investigation. You can contact Technical
Support using the form on this page:

http://www.mathworks.com/company/aboutus/contact_us/

Alternately, you could try profiling your code (as Bruno suggested) and post
a small chunk of code that the Profiler indicates is a bottleneck to see if
any of the readers here have suggestions for how to improve the performance
of that code.

--
Steve Lord
slord@mathworks.com

Hi Steven,

I ran the profiler and the bottleneck is interp3 - the built-in 3d interpolation routine. Within interp3 it's repmat and meshgrid.

Thanks for your reply!

Best

Pontus

"Steven Lord" <slord@mathworks.com> wrote in message <gd0cos$ojb$1@fred.mathworks.com>...
>
> "Pontus " <pontus.rendahl@gmail.com> wrote in message
> news:gd0c0g$gvd$1@fred.mathworks.com...
> > Hi Bruno,
> >
> > Thanks for your reply. The facts, however, remain: Running the SAME
> > program on the SAME computer yields different CPU times for different
> > versions of MATLAB. The older version is MUCH faster.
> >
> > Anyone?
>
> Without being able to see the code (or at the VERY least seeing the Profiler
> report created from running the code in the MATLAB Profiler) any explanation
> or suggestions as to why you're seeing what you're seeing would be no better
> than a guess or a shot in the dark. Therefore I recommend you send your
> code to Technical Support for investigation. You can contact Technical
> Support using the form on this page:
>
> http://www.mathworks.com/company/aboutus/contact_us/
>
> Alternately, you could try profiling your code (as Bruno suggested) and post
> a small chunk of code that the Profiler indicates is a bottleneck to see if
> any of the readers here have suggestions for how to improve the performance
> of that code.
>
> --
> Steve Lord
> slord@mathworks.com
>

Pontus <pontus.rendahl@gmail.com> wrote:
> Hi all,
>
> I've run a pretty demanding program in both matlab 7.1 and 7.6 on the
> exakt same computer. What takes 4.3 seconds in 7.1 takes 11.5 seconds in
> 7.6! How is this possible? Is matlab getting slower for each release, or
> when did this happen??
>

As others have said, without specifics it is difficult to reproduce your
findings and to offer suggestions for improvement. Post a subset of your
code to let others see what is going on.


>
> PS. Oh, and since 7.1 doesn't run on Vista, and I thus have to use 7.6,
> this means that my new state of the art laptop runs equally fast as my
> three years old shitty HP. This sucks.
>

I'm not sure what the reason is that you can't run MATLAB 7.1 under Vista.
I have a copy of MATLAB 6.5 working happily. My only issue is that I have
to start the FLEXlm license manager manually. I still haven't got to the
bottom of that one, but as far as I can see it is a FLEXlm problem, not a
MATLAB one.


--
Dr Tristram J. Scott
Energy Consultant

Hi Pontus,

Matlab's interp functions are slow, we implemented them in C and compiled as a mex function and it runs up to x25 times faster. See an example on file exchange

http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=8627&objectType=file

>>Hi Mikhail,

>>Thanks for the recommendation at Matlab newsreader. I >>will take a look at your MEX files.

>>Do you, incidently, know whether Fortran or C produces >>the best codes for MEX?

>>Best
>>Pontus

Hi Pontus,

i do not know but I think that C can not be worse then fortran. It depends more on the compiler then on the language. There can be different compilers for C in matlab, I do not know which is better.

If you make some assumptions about your data you can optimize your interpolation still further, it a strong point for custom implementation against general matlab implementation:

1. If your datapoints is a continuous curve (measurement) then neighbour points probably lie between same nodes.
2. The nodes are ordered per definition --> you should use divide and conquer approach (vs. linear search)

Best
Mikhail

Mikhail <razum@gmx.com> wrote in message <26589987.1224057019459.JavaMail.jakarta@nitrogen.mathforum.org>...
> >>Hi Mikhail,
>
> >>Thanks for the recommendation at Matlab newsreader. I >>will take a look at your MEX files.
>
> >>Do you, incidently, know whether Fortran or C produces >>the best codes for MEX?
>
> >>Best
> >>Pontus
>
> Hi Pontus,
>
> i do not know but I think that C can not be worse then fortran. It depends more on the compiler then on the language. There can be different compilers for C in matlab, I do not know which is better.
>
> If you make some assumptions about your data you can optimize your interpolation still further, it a strong point for custom implementation against general matlab implementation:
>
> 1. If your datapoints is a continuous curve (measurement) then neighbour points probably lie between same nodes.
> 2. The nodes are ordered per definition --> you should use divide and conquer approach (vs. linear search)

Linear search??

There's a joke about an Irishman painting a white line on a road... Fill in the punchline yourself.

Hi Steve,

you mean probably "Shlemiel the painter's algorithm":
http://www.joelonsoftware.com/articles/fog0000000319.html

well, I referred to the my prevoius post where I suggested:
http://www.mathworks.com/matlabcentral/fileexchange/loadFile.do?objectId=8627

It is a good example of a mex implementation EXCEPT that it uses linear search.

Ok here is some sample code that is SIGNIFICANTLY slower on R2008a than R14:

% Begin code
clear;

n = 400;

for i = 1:n
for j = 1:n
for k = 1:n
A(i,j,k) = rand;
end
end
end

% End code

I know that this is a silly piece of code, and I also know several ways to speed it up, so that is not my problem. (so please don't give any advice on how to vectorize the above or initiate with A=zeros(n,n,n), or something) The point is that very simple code is at least 50% faster in Matlab R14 (or 7.1) than in R2008a!!!

Does anybody know why???

Pontus


"Pontus " <pontus.rendahl@gmail.com> wrote in message <gd07t7$6nq$1@fred.mathworks.com>...
> Hi all,
>
> I've run a pretty demanding program in both matlab 7.1 and 7.6 on the exakt same computer. What takes 4.3 seconds in 7.1 takes 11.5 seconds in 7.6! How is this possible? Is matlab getting slower for each release, or when did this happen??
>
> Hope you can inform me
>
> Best
>
> PS. Oh, and since 7.1 doesn't run on Vista, and I thus have to use 7.6, this means that my new state of the art laptop runs equally fast as my three years old shitty HP. This sucks.

"Pontus " <pontus.rendahl@gmail.com> wrote in message <gd5261$2nb$1@fred.mathworks.com>...

>
> Does anybody know why???

First remark:
Randomness of the fragmentation of the memory? When one does not allocate array before hand and run such code, the amount of reallocating depends on a specific fragmentation at instant t and not much on the engine behind.

The time you provide does not prove anything solid. Indeed, I just run the code on the same MATLAB 7.6 and I get 50% variation of CPU. Similar discrepency between 7.3 and 7.6, in defavor of 7.3.

Second remark:
From 7.4 rand calls for a new method of Mersenne Twister which has better statistic properties than the old SWB method on 7.1. So actually your two RAND is not the same.

Bruno

Bruno, do you seriously think I get significantly and repeatedly different results from 7.1 and R2008a due to randomness of the fragmentation of the memory, or the randomization algorithm? The results maintain when I solve a very tedious dynamic model that takes half an hour.

In addition, the following code gives the same results:

n = 400;

A = ones(n,n,n);
for i = 1:n
    for j= 1:n
        for k = 1:n
            A(i,j,k) = 1;
        end
    end
end

(and I can run it a thousand times on each version and take CPU-time averages if you wanna, the results are still the same)

Has anyone else tried to compare 7.1 with R2008a???

Pontus



"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <gd59ia$7f7$1@fred.mathworks.com>...
> "Pontus " <pontus.rendahl@gmail.com> wrote in message <gd5261$2nb$1@fred.mathworks.com>...
>
> >
> > Does anybody know why???
>
> First remark:
> Randomness of the fragmentation of the memory? When one does not allocate array before hand and run such code, the amount of reallocating depends on a specific fragmentation at instant t and not much on the engine behind.
>
> The time you provide does not prove anything solid. Indeed, I just run the code on the same MATLAB 7.6 and I get 50% variation of CPU. Similar discrepency between 7.3 and 7.6, in defavor of 7.3.
>
> Second remark:
> From 7.4 rand calls for a new method of Mersenne Twister which has better statistic properties than the old SWB method on 7.1. So actually your two RAND is not the same.
>
> Bruno

"Pontus " <pontus.rendahl@gmail.com> wrote in message <gd5lq6$emp$1@fred.mathworks.com>...
> Bruno, do you seriously think I get significantly and repeatedly different results from 7.1 and R2008a due to randomness of the fragmentation of the memory, or the randomization algorithm? The results maintain when I solve a very tedious dynamic model that takes half an hour.

Yes I have tested it as I though above, IIRC

- 190s for 7.3 and
- 120 s for 7.7 run 1
- 170 s for 7.7 run 2

Sorry but I'm not quite convinced by your way of doing benchmark.

Bruno

In article <gd5lq6$emp$1@fred.mathworks.com>,
 "Pontus " <pontus.rendahl@gmail.com> wrote:

> Bruno, do you seriously think I get significantly and repeatedly different
> results from 7.1 and R2008a due to randomness of the fragmentation of the
> memory, or the randomization algorithm? The results maintain when I solve a
> very tedious dynamic model that takes half an hour.
>
> In addition, the following code gives the same results:
>
> n = 400;
>
> A = ones(n,n,n);
> for i = 1:n
> for j= 1:n
> for k = 1:n
> A(i,j,k) = 1;
> end
> end
> end
>
> (and I can run it a thousand times on each version and take CPU-time averages
> if you wanna, the results are still the same)
>
> Has anyone else tried to compare 7.1 with R2008a???
>
> Pontus


I no longer have 7.1 so I can't try it myself, but just for fun try
replacing

  A(i,j,k) = 1;

with

  A(k,j,i) = 1;

and see if it makes a difference. The way you are doing it requires
accessing memory locations that are far apart whereas with my way the
memory locations are contiguous. With n = 400, I get about 3.5 sec your
way and 2 sec my way. (R2008a on a Mac)

--
Doug Schwarz
dmschwarz&ieee,org
Make obvious changes to get real email address.

Doug Schwarz <see@sig.for.address.edu> wrote in message <see-F4434E.21005415102008@news.frontiernet.net>...
> In article <gd5lq6$emp$1@fred.mathworks.com>,
> "Pontus " <pontus.rendahl@gmail.com> wrote:
>
> > Bruno, do you seriously think I get significantly and repeatedly different
> > results from 7.1 and R2008a due to randomness of the fragmentation of the
> > memory, or the randomization algorithm? The results maintain when I solve a
> > very tedious dynamic model that takes half an hour.
> >
> > In addition, the following code gives the same results:
> >
> > n = 400;
> >
> > A = ones(n,n,n);
> > for i = 1:n
> > for j= 1:n
> > for k = 1:n
> > A(i,j,k) = 1;
> > end
> > end
> > end
> >
> > (and I can run it a thousand times on each version and take CPU-time averages
> > if you wanna, the results are still the same)
> >
> > Has anyone else tried to compare 7.1 with R2008a???
> >
> > Pontus
>
>
> I no longer have 7.1 so I can't try it myself, but just for fun try
> replacing
>
> A(i,j,k) = 1;
>
> with
>
> A(k,j,i) = 1;
>
> and see if it makes a difference. The way you are doing it requires
> accessing memory locations that are far apart whereas with my way the
> memory locations are contiguous. With n = 400, I get about 3.5 sec your
> way and 2 sec my way. (R2008a on a Mac)
>
> --
> Doug Schwarz
> dmschwarz&ieee,org
> Make obvious changes to get real email address.

Doug, Bruno and the others,

I have found the problem. It was really with interp3 that is several times slower for r2008a than for r14. Replacing the new interp3 with the old one completely solved my problem. It might be worth knowing for the Mathworks guys!

Thanks for helping out!

"Pontus " <pontus.rendahl@gmail.com> wrote in message <gd651m$dhq$1@fred.mathworks.com>...

>
> Doug, Bruno and the others,
>
> I have found the problem. It was really with interp3 that is several times slower for r2008a than for r14. Replacing the new interp3 with the old one completely solved my problem. It might be worth knowing for the Mathworks guys!
>
> Thanks for helping out!

Can you please post a snip code how you call interp3 and provide us information about:

1. Interpolation method
2. Dimension of the parameters (size)
3. where as the output is gridded or scattered points
4. Memory available when interp3 is called (e.g., use 'monitormatlab' in FEX).

Bruno

"Pontus " <pontus.rendahl@gmail.com> wrote in message
news:gd651m$dhq$1@fred.mathworks.com...
> Doug Schwarz <see@sig.for.address.edu> wrote in message
> <see-F4434E.21005415102008@news.frontiernet.net>...
>> In article <gd5lq6$emp$1@fred.mathworks.com>,
>> "Pontus " <pontus.rendahl@gmail.com> wrote:

*snip*

> Doug, Bruno and the others,
>
> I have found the problem. It was really with interp3 that is several times
> slower for r2008a than for r14. Replacing the new interp3 with the old one
> completely solved my problem. It might be worth knowing for the Mathworks
> guys!

Pontus,

Can you send either to technical support or to me directly a small(ish)
example that takes several times as long in release R2008a as in release R14
so that we can investigate the cause of the slowdown?

--
Steve Lord
slord@mathworks.com

Bruno and Steven,

I can't answer all your questions since I've uninstalled Matlab R14 now. But here is the bottleneck code:

[Kemat,kmat,Kumat] = meshgrid(Ke,kp,Ku);

for ii=1:2
    for i=1:2
        for j=1:NK
            for l=1:NK
                kpp1(:,j,l,i,ii) = interp3(Kemat,kmat,Kumat,kpmat(:,:,:,1,i),KpeN(j,l,i,ii),kp,KpuN(j,l,i,ii));
                kpp2New(:,j,l,i,ii) = interp3(Kemat,kmat,Kumat,kpmat(:,:,:,2,i),KpeN(j,l,i,ii),kp,KpuN(j,l,i,ii));
            end
        end
    end
end

Where Ke is (12 x 1), Ku is (12 x 1), and kp is (250 x 1). NK = 12. interp3 is thus called 2*576 times and then spits out a 250 by 1 vector (while KpeN(j,l,i,ii) and KpuN(j,l,i,ii) are scalars, kp is a 250 by 1 vector). I iterate on this (plus some other stuff of course) procedure around 2000 times, so no wonder speed of interp3 was a concern.

So Steve, I'm not sure what is going wrong in the new interp3. It could be that kp is a vector, but it could also be that it performs more "tests" on the inputs and thus slows things down.

Best

Pontus

"Steven Lord" <slord@mathworks.com> wrote in message <gd7j6v$c30$1@fred.mathworks.com>...
>
> "Pontus " <pontus.rendahl@gmail.com> wrote in message
> news:gd651m$dhq$1@fred.mathworks.com...
> > Doug Schwarz <see@sig.for.address.edu> wrote in message
> > <see-F4434E.21005415102008@news.frontiernet.net>...
> >> In article <gd5lq6$emp$1@fred.mathworks.com>,
> >> "Pontus " <pontus.rendahl@gmail.com> wrote:
>
> *snip*
>
> > Doug, Bruno and the others,
> >
> > I have found the problem. It was really with interp3 that is several times
> > slower for r2008a than for r14. Replacing the new interp3 with the old one
> > completely solved my problem. It might be worth knowing for the Mathworks
> > guys!
>
> Pontus,
>
> Can you send either to technical support or to me directly a small(ish)
> example that takes several times as long in release R2008a as in release R14
> so that we can investigate the cause of the slowdown?
>
> --
> Steve Lord
> slord@mathworks.com
>

"Pontus " <pontus.rendahl@gmail.com> wrote in message <gd7s9q$hdj$1@fred.mathworks.com>...
> Bruno and Steven,
>
> I can't answer all your questions since I've uninstalled Matlab R14 now. But here is the bottleneck code:
>
> [Kemat,kmat,Kumat] = meshgrid(Ke,kp,Ku);
>
> for ii=1:2
> for i=1:2
> for j=1:NK
> for l=1:NK
> kpp1(:,j,l,i,ii) = interp3(Kemat,kmat,Kumat,kpmat(:,:,:,1,i),KpeN(j,l,i,ii),kp,KpuN(j,l,i,ii));
> kpp2New(:,j,l,i,ii) = interp3(Kemat,kmat,Kumat,kpmat(:,:,:,2,i),KpeN(j,l,i,ii),kp,KpuN(j,l,i,ii));
> end
> end
> end
> end
>
> Where Ke is (12 x 1), Ku is (12 x 1), and kp is (250 x 1). NK = 12. interp3 is thus called 2*576 times and then spits out a 250 by 1 vector (while KpeN(j,l,i,ii) and KpuN(j,l,i,ii) are scalars, kp is a 250 by 1 vector). I iterate on this (plus some other stuff of course) procedure around 2000 times, so no wonder speed of interp3 was a concern.
>
> So Steve, I'm not sure what is going wrong in the new interp3. It could be that kp is a vector, but it could also be that it performs more "tests" on the inputs and thus slows things down.
>

I'm sorry, but this kind of code is *very* bad for Matlab. Matlab functions such as interp3 has large overhead (sorting data, put them on patch) that becomes negligible when call with a large enough matrix. In your code the for three loop on (ii,j,l) can be vectorized with one call. Instead of that you call it separately, that meant the same overhead are called over and over again.

True might be the overhead of interp3 in 7.7 is more complex and bigger and slower than 7.1, but this is OK if the program is designed in the Matlab spirit, and not OK for the codes with unnecessary for-loop. This might explain why it's slower.

I bet Mathworks developers would *not* design and optimize the newer Matlab version with this kind of code in mind.

I'm sorry to say Pontus, but might be this is an opportunity for you to make few clean up in your code. Otherwise there is no point of updating to newer Matlab version.

Bruno

"Pontus " <pontus.rendahl@gmail.com> wrote in message
news:gd7s9q$hdj$1@fred.mathworks.com...
> Bruno and Steven,
>
> I can't answer all your questions since I've uninstalled Matlab R14 now.
> But here is the bottleneck code:
>
> [Kemat,kmat,Kumat] = meshgrid(Ke,kp,Ku);
>
> for ii=1:2
> for i=1:2
> for j=1:NK
> for l=1:NK
> kpp1(:,j,l,i,ii) =
> interp3(Kemat,kmat,Kumat,kpmat(:,:,:,1,i),KpeN(j,l,i,ii),kp,KpuN(j,l,i,ii));
> kpp2New(:,j,l,i,ii) =
> interp3(Kemat,kmat,Kumat,kpmat(:,:,:,2,i),KpeN(j,l,i,ii),kp,KpuN(j,l,i,ii));
> end
> end
> end
> end
>
> Where Ke is (12 x 1), Ku is (12 x 1), and kp is (250 x 1). NK = 12.
> interp3 is thus called 2*576 times and then spits out a 250 by 1 vector
> (while KpeN(j,l,i,ii) and KpuN(j,l,i,ii) are scalars, kp is a 250 by 1
> vector). I iterate on this (plus some other stuff of course) procedure
> around 2000 times, so no wonder speed of interp3 was a concern.
>
> So Steve, I'm not sure what is going wrong in the new interp3. It could be
> that kp is a vector, but it could also be that it performs more "tests" on
> the inputs and thus slows things down.

I'd like to give the developer in charge of interp3 this example so he can
investigate it. Can you send me Ke, kp, Ku, kpmat, KpeN, and KpuN in a
separate email (either as text or as a MAT-file, preferably as a MAT-file if
they contain noninteger values, to preserve the precision)? If you can't
because it's confidential or because you don't have it anymore, that's okay,
but having the actual data would allow us to run the example and would help
us determine the cause of the slowdown.

--
Steve Lord
slord@mathworks.com

without a description of the complexity of your code it is very difficult for us to assess the performance given such a brief description of what you are trying to do.

nevertheless, i have to agree with other members of the forum, i have found the latest release to be quicker.

Pontus,

I'm pretty sure now my assumption about extra overhead in interp3 stands. Here is what I did: I run and bench mark your code with for-loop under 7.3 and 7.7, then vectorize it and run the same. Now here is the result:

FOR-LOOP: 7sec on V7.3 and 14s on V7.7
VECTORIZED: 1.8sec on V7.3 and 1.32sec on V7.7

So the conclusion is the over-head of 7.7 is slower. Here is the code. Run it yourself:

%%%%%%%%%%%%%%%%%%%%%%%%%%
% DATA
Ke=(1:12)/12;
Ku=(1:12)/12;
kp=(1:250)/250;
[Kemat,kmat,Kumat] = meshgrid(Ke,kp,Ku);

kpmat=randn([size(Kemat) 2 2]);
NK=24;
KpeN=rand(NK,NK,2,2);
KpuN=rand(NK,NK,2,2);

% FOR-LOOP
tic
kpp1=zeros(numel(kp),NK,NK,2,2);
kpp2New=zeros(numel(kp),NK,NK,2,2);
for ii=1:2
    for i=1:2
        for j=1:NK
            for l=1:NK
                kpp1(:,j,l,i,ii) = interp3(Kemat,kmat,Kumat,kpmat(:,:,:,1,i),KpeN(j,l,i,ii),kp,KpuN(j,l,i,ii));
                kpp2New(:,j,l,i,ii) = interp3(Kemat,kmat,Kumat,kpmat(:,:,:,2,i),KpeN(j,l,i,ii),kp,KpuN(j,l,i,ii));
            end
        end
    end
end
toc % 7.005008 s on ML 7.3
    % 14.232357 s on ML 7.7.

% VECTORIZED VECTION: Avoid OVERHEAD
tic
kpp1=zeros(numel(kp),NK,NK,2,2);
kpp2New=zeros(numel(kp),NK,NK,2,2);
nkp=numel(kp);
for i=1:2
    KPEN=reshape(KpeN(:,:,i,:),[1 NK NK 1 2]);
    KPEN=repmat(KPEN,[nkp 1 1 1 1]);
    
    KPUN=reshape(KpuN(:,:,i,:),[1 NK NK 1 2]);
    KPUN=repmat(KPUN,[nkp 1 1 1 1]);
    
    KP=repmat(kp(:),[1 NK NK 1 2]);
    
    kpp1(:,:,:,i,:) = interp3(Kemat,kmat,Kumat,kpmat(:,:,:,1,i),KPEN,KP,KPUN);
    kpp2New(:,:,:,i,:) = interp3(Kemat,kmat,Kumat,kpmat(:,:,:,2,i),KPEN,KP,KPUN);
end
toc % 1.802838. Matlab 7.3
    % 1.319979 seconds.


% Bruno

I've a similar problem. I tested with a very simple code:

test.m -----------------
tic
N=500;
nc=100000;
poblacion=rand(N);
valor=zeros(N,1);

for i=1:size(poblacion,1)
    valor(i)=norm(poblacion(i,:));
    for k=1:nc
        k=k+1;
        k^2;
        sqrt(k);
    end
end
toc
-----------------------------

The results are with the same computer:
matlab version 6.5.1 : 2.5 sec
matlab version 7.1SP3 : 6.7 sec
matlab version R2006a : 8.8 sec
matlab version R2006b : 8.3 sec
matlab version R2007a : 23.8 sec
matlab version R2007b : 22.7 sec
matlab version R2008a : 20.5 sec

Profile tool didn't show why this happens only the Lines where the most time was spent. But in this case (very simple operations) is not very helpful.

Why does it happen?

Best regards

"Xavier " <djembe@eresmas.com> wrote in message <ge4slc$h20$1@fred.mathworks.com>...

>
> Why does it happen?
>

When you evaluate an expression without putting the result in the variable, such as this

        k=k+1;
        k^2;
        sqrt(k);

Overhead (such as ANS to save the values) is called and this introduces a bias in timing.

Try to time by replacing the above with these:

  a=k+1;
  b=k^2;
  c=sqrt(k);

Please please, bear in mind that Matlab does all kind of overheads, and do not make benchmarks with strange instructions that are not often used in normal Matlab programming.

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <ge4ue4$72e$1@fred.mathworks.com>...
> "Xavier " <djembe@eresmas.com> wrote in message <ge4slc$h20$1@fred.mathworks.com>...
>
> >
> > Why does it happen?
> >
>
> When you evaluate an expression without putting the result in the variable, such as this
>
> k=k+1;
> k^2;
> sqrt(k);
>
> Overhead (such as ANS to save the values) is called and this introduces a bias in timing.
>
> Try to time by replacing the above with these:
>
> a=k+1;
> b=k^2;
> c=sqrt(k);
>
> Please please, bear in mind that Matlab does all kind of overheads, and do not make benchmarks with strange instructions that are not often used in normal Matlab programming.
 
 
I confirm that R13 is considerably faster (> 3x), though the timings show a large spread.
 
R13 - between 1.5 and 5 secs
R2007b - once 6.5 but most of times ~10 secs
 
This independently of having k^2; or b = k^2;

"Pasco Alquim" <pasquimm@yahoo.com> wrote in message <ge5557$f4j$1@fred.mathworks.com>...

>
>
> I confirm that R13 is considerably faster (> 3x), though the timings show a large spread.
>
> R13 - between 1.5 and 5 secs
> R2007b - once 6.5 but most of times ~10 secs
>

This does confirm surely one thing: you guys time something else and not the calculation itself. I cannot test R13, because I'm running Vista. The benchmark times I get on 2006B and 2008b are consistent, and there is a clear distinction between affectation and non-affectation.

Please stop doing benchmark with meaningless for-loop stuff. Do it with a vectorized code, such as the interp3 submitted by Pontus, and report us the results:

%%%%%%%%%%%%%%%

clear all
% DATA
Ke=(1:12)/12;
Ku=(1:12)/12;
kp=(1:250)/250;
[Kemat,kmat,Kumat] = meshgrid(Ke,kp,Ku);

kpmat=randn([size(Kemat) 2 2]);
NK=24;
KpeN=rand(NK,NK,2,2);
KpuN=rand(NK,NK,2,2);

% VECTORIZED VECTION: Avoid OVERHEAD
for ntest=1:10
    tic;
    kpp1=zeros(numel(kp),NK,NK,2,2);
    kpp2New=zeros(numel(kp),NK,NK,2,2);
    nkp=numel(kp);
    for i=1:2
        KPEN=reshape(KpeN(:,:,i,:),[1 NK NK 1 2]);
        KPEN=repmat(KPEN,[nkp 1 1 1 1]);
        
        KPUN=reshape(KpuN(:,:,i,:),[1 NK NK 1 2]);
        KPUN=repmat(KPUN,[nkp 1 1 1 1]);
        
        KP=repmat(kp(:),[1 NK NK 1 2]);
        
        kpp1(:,:,:,i,:) = interp3(Kemat,kmat,Kumat,kpmat(:,:,:,1,i),KPEN,KP,KPUN);
        kpp2New(:,:,:,i,:) = interp3(Kemat,kmat,Kumat,kpmat(:,:,:,2,i),KPEN,KP,KPUN);
    end
    time(ntest)=toc;
end

version
median(time)

% Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <ge5bul$kva$1@fred.mathworks.com>...
> "Pasco Alquim" <pasquimm@yahoo.com> wrote in message <ge5557$f4j$1@fred.mathworks.com>...
>
> >
> >
> > I confirm that R13 is considerably faster (> 3x), though the timings show a large spread.
> >
> > R13 - between 1.5 and 5 secs
> > R2007b - once 6.5 but most of times ~10 secs
> >
>
> This does confirm surely one thing: you guys time something else and not the calculation itself. I cannot test R13, because I'm running Vista. The benchmark times I get on 2006B and 2008b are consistent, and there is a clear distinction between affectation and non-affectation.
  
 
 
> Please stop doing benchmark with meaningless for-loop stuff.
 
Pardon ????
 
 
Reduce it to a sqrt() issue (still a lot of spread)
 
t=cputime;
for k=1:50000000
    c=sqrt(k);
end
cputime-t
 
 
R13 - between 2.5 and 4 secs
R2007b - between 8 and 10 secs

"Pasco Alquim" <pasquimm@yahoo.com> wrote in message <ge5fkp$hrr$1@fred.mathworks.com>...
> "Bruno Luong" <b.luong@fogale.findmycountry> wrote in
>
> Pardon ????
>

Could you try this:

clear
tic
for l=1:10
    k=1:5000000;
    sqrtk=sqrt(k);
end
toc

Thanks,

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <ge5g7i$p0b$1@fred.mathworks.com>...
> "Pasco Alquim" <pasquimm@yahoo.com> wrote in message <ge5fkp$hrr$1@fred.mathworks.com>...
> > "Bruno Luong" <b.luong@fogale.findmycountry> wrote in
> >
> > Pardon ????
> >
>
> Could you try this:
>
> clear
> tic
> for l=1:10
> k=1:5000000;
> sqrtk=sqrt(k);
> end
> toc
>
> Thanks,
>
> Bruno
 
 
R13 - 1.7 to 2.7 secs
R2007b - 4.0 to 4.3
 
And that is with cputime. Not tic-toc
 
Pasco

"Pasco Alquim" <pasquimm@yahoo.com> wrote in message <ge5h64$bbu$1@fred.mathworks.com>...

> R13 - 1.7 to 2.7 secs
> R2007b - 4.0 to 4.3
>

Thank you. This ought to be explained by Mathworks.... :-( I might dig out my XP computer and try it myself.

Bruno

"Pasco Alquim" <pasquimm@yahoo.com> wrote in message <ge5h64$bbu$1@fred.mathworks.com>...

>
> And that is with cputime. Not tic-toc
>

Here is a highlight of Mathworks recommendation of cputime vs tic/toc:

[ Although it is possible to measure performance using the cputime function, it is recommended that you use the tic and toc functions for this purpose exclusively. It has been the general rule for CPU-intensive calculations run on Microsoft Windows machines that the elapsed time using cputime and the elapsed time using tic and toc are close in value, ignoring any first time costs. There are cases however that show a significant difference between these two methods. For example, in the case of a Pentium 4 with hyperthreading running Windows, there can be a significant difference between the values returned by cputime versus tic and toc. ]

On what processor do you run your sqrt test? Is your computer Bios is set with and without hyperthreading?

Bruno

"Bruno Luong" <b.luong@fogale.findmycountry> wrote in message <ge68sv$drl$1@fred.mathworks.com>...
> "Pasco Alquim" <pasquimm@yahoo.com> wrote in message <ge5h64$bbu$1@fred.mathworks.com>...
>
> >
> > And that is with cputime. Not tic-toc
> >
>
> Here is a highlight of Mathworks recommendation of cputime vs tic/toc:
>
> [ Although it is possible to measure performance using the cputime function, it is recommended that you use the tic and toc functions for this purpose exclusively. It has been the general rule for CPU-intensive calculations run on Microsoft Windows machines that the elapsed time using cputime and the elapsed time using tic and toc are close in value, ignoring any first time costs. There are cases however that show a significant difference between these two methods. For example, in the case of a Pentium 4 with hyperthreading running Windows, there can be a significant difference between the values returned by cputime versus tic and toc. ]
>
> On what processor do you run your sqrt test? Is your computer Bios is set with and without hyperthreading?
 
Using tic toc or cputime is irrelevant (I'm using a 2.5 Core Duo)

However, I found a new thing
 
with R2007b using sqrtk=sqrt(k); or sqrtk=k.^0.5;
is the same. But with R13, sqrtk=k.^0.5; takes ~8 secs

I reinstall R14 on an XP computer and time the above square-root loop and indeed 2007b is significantly slower. I hope someone from Mathworks (Steve) can shed a light.

Bruno

I ran a program to solve parabolic diffusive equation. It took the amount of time on the following platforms for the same code:

vista:
      matlab 9a: 101 seconds
      matlab 7a: 69 seconds

xp:
      matlab 8b: 220 seconds
      matlab 6.5: 166 seconds

is this a known issue for matlab?

HJ

I myself have run across codes that run noticeably faster on 6.5 than on 2007a,b (not counting the initialization of Matlab itself, which is WAY slower on 2007a,b). I cannot recall what they were now, because it doesn't happen often, but it can happen.

"Matt Fig" <spamanon@yahoo.com> wrote in message <gtflhi$pso$1@fred.mathworks.com>...
> I myself have run across codes that run noticeably faster on 6.5 than on 2007a,b (not counting the initialization of Matlab itself, which is WAY slower on 2007a,b). I cannot recall what they were now, because it doesn't happen often, but it can happen.

I have the same problem!!!
I do combustion simulation with 7.1 and 7.7, everytime 7.1 is about 15% faster.
Considering it takes hours to simulate, 15% is enormous.

"Gaojun " <gaojun.shen@gmail.com> wrote in message <gtp24a$qb1$1@fred.mathworks.com>...
> "Matt Fig" <spamanon@yahoo.com> wrote in message <gtflhi$pso$1@fred.mathworks.com>...
> > I myself have run across codes that run noticeably faster on 6.5 than on 2007a,b (not counting the initialization of Matlab itself, which is WAY slower on 2007a,b). I cannot recall what they were now, because it doesn't happen often, but it can happen.
>
> I have the same problem!!!
> I do combustion simulation with 7.1 and 7.7, everytime 7.1 is about 15% faster.
> Considering it takes hours to simulate, 15% is enormous.

I guess many of you use multiple-core processor. If so, please note in Matlab 7.7 and 7.8, the default setting is to use all cores available. To check, try maxNumCompThreads

To compare with old version Matlab more accurately, the multi-core support should be switched off. Try

maxNumCompThreads(1)

before any time test.

On my PC, the follwoing code runs faster in 7.7 and 7.8 than in 7.3

A= rand(1,1000000);
tic, for k=1:100, B=sqrt(A); end, toc

In 7.7 and 7.8, it takes about 1.5 seconds, but it takes about 3 seconds in 7.3.

Yi Cao