compare the executive speed with Matlab

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: compare the executive speed with Matlab

Howard-33
Hi Michael,

Thanks for your reply.
The attached files are codes for testing the executive time.
As you can see that below are my executive result, it looks Octave's
executive speed is slower than Matlab. I thought Octave should be better
than Matlab. Do you have any idea about it?

Thanks!

*Octave on Ubuntu Linux
ExecutiveTime.m  3.876s
BinomialEuro.m  20.8s
BlackScholesEuro.m  0.0594s

*Octave on Windows
ExecutiveTime.m  9.97s
BinomialEuro.m  41.1s
BlackScholesEuro  0.235s

*Matlab on Windows
ExecutiveTime.m  0.0176s
BinomialEuro.m  0.092721s
BlackScholesEuro  0.000835s

Best regards,

Howard Su

_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave

BinomialEuro.m (1K) Download Attachment
BlackScholesEuro.m (1K) Download Attachment
ExecutiveTime.m (74 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: compare the executive speed with Matlab

Jaroslav Hajek-2
On Sat, Jan 3, 2009 at 6:40 PM, Howard <[hidden email]> wrote:
> Hi Michael,
>
> Thanks for your reply.
> The attached files are codes for testing the executive time.
> As you can see that below are my executive result, it looks Octave's
> executive speed is slower than Matlab. I thought Octave should be better
> than Matlab. Do you have any idea about it?
>

I just wonder why did you think that?


> Thanks!
>
> *Octave on Ubuntu Linux
> ExecutiveTime.m  3.876s
> BinomialEuro.m  20.8s
> BlackScholesEuro.m  0.0594s
>
> *Octave on Windows
> ExecutiveTime.m  9.97s
> BinomialEuro.m  41.1s
> BlackScholesEuro  0.235s
>
> *Matlab on Windows
> ExecutiveTime.m  0.0176s
> BinomialEuro.m  0.092721s
> BlackScholesEuro  0.000835s
>
> Best regards,
>
> Howard Su
>

ExecutiveTime and BinomialEuro are loopy, so there's no big surprise -
Matlab does JIT compiling, Octave does not, and probably won't in the
near future.
Btw, BinomialEuro can be easily vectorized, which I suppose would
reduce the speed penalty significantly. Another option is to make it a
compiled function.

BlackScholesEuro is a different story - apparently something is done
significantly more slowly.


--
RNDr. Jaroslav Hajek
computing expert
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz
_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: compare the executive speed with Matlab

wim van hoydonck
In reply to this post by Sergei Steshenko
On 1/3/09, Sergei Steshenko <[hidden email]> wrote:

>
>
>
>  --- On Fri, 1/2/09, wim van hoydonck <[hidden email]> wrote:
>
>  > From: wim van hoydonck <[hidden email]>
>
> > Subject: Re: compare the executive speed with Matlab
>  > To: [hidden email]
>
> > Cc: "John W. Eaton" <[hidden email]>, [hidden email], "Howard" <[hidden email]>
>
>  [snip]
>
>
>  >   angles = real( [(i, i=0,n-1)]/n , kind=dp )
>
>
> [snip]
>
>  'pi' appears to be missing in the line above, but I'm unfamiliar with
>  f90 syntax, so I do not know how fix the line, probably
>
>   angles = real( pi * [(i, i=0,n-1)]/n , kind=dp )
>
>  Regards,
>
>   Sergei.
>
>
>
>

Hi Sergei,

You are right, 'pi' was in the wrong place.

About the timing differences:
It might be that, due to optimizations, ifort already calculates the
result (the sinus of the angles) at compile time (as that is something
that can be calculated in advance), but I am not sure about that.

Anyway, the speed difference here is not that big, it becomes more
apparent with larger programs that contain multiple for/do loops.
I've seen a speed increase of 1000 between matlab and fortran on a
program that contained a double loop, from 25 minutes of calculation
time to 1.5 seconds...

But there are obviously also nontrivial problems where fortran
(gfortran, ifort,...) is not faster and even slower (see here:
http://shootout.alioth.debian.org/gp4/).

Greetings,

wim
_______________________________________________
Help-octave mailing list
[hidden email]
https://www-old.cae.wisc.edu/mailman/listinfo/help-octave
12