help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Re: Octave versus matlab performances on linux platform 64 bits


From: highegg
Subject: Re: Re: Octave versus matlab performances on linux platform 64 bits
Date: Thu, 30 Oct 2008 03:15:01 -0700

On Oct 30, 2008 10:44am, Luca Tagliacozzo <address@hidden> wrote:
> running ldd on octave gives:
> ldd /usr/bin/octave
>         linux-vdso.so.1 =>  (0x00007fff7c9fe000)
>         liboctinterp.so => /usr/lib/octave-3.0.0/liboctinterp.so (0x00007ff1739f1000)
>         liboctave.so => /usr/lib/octave-3.0.0/liboctave.so (0x00007ff172f5f000)
>
>         libcruft.so => /usr/lib/octave-3.0.0/libcruft.so (0x00007ff172cfc000)
>         libumfpack.so.3.1.0 => /usr/lib/libumfpack.so.3.1.0 (0x00007ff172a51000)
>         libamd.so.3.1.0 => /usr/lib/libamd.so.3.1.0 (0x00007ff172849000)
>
>         libcamd.so.3.1.0 => /usr/lib/libcamd.so.3.1.0 (0x00007ff172640000)
>         libcolamd.so.3.1.0 => /usr/lib/libcolamd.so.3.1.0 (0x00007ff17243a000)
>         libcholmod.so.3.1.0 => /usr/lib/libcholmod.so.3.1.0 (0x00007ff17215a000)
>
>         libccolamd.so.3.1.0 => /usr/lib/libccolamd.so.3.1.0 (0x00007ff171f50000)
>         libcxsparse.so.3.1.0 => /usr/lib/libcxsparse.so.3.1.0 (0x00007ff171d24000)
>         liblapack.so.3gf => /usr/lib/liblapack.so.3gf (0x00007ff171388000)
>
>         libblas.so.3gf => /usr/lib/libblas.so.3gf (0x00007ff17110e000)
>         libfftw3.so.3 => /usr/lib/libfftw3.so.3 (0x00007ff170e51000)
>         libreadline.so.5 => /lib/libreadline.so.5 (0x00007ff170c11000)
>
>         libncurses.so.5 => /lib/libncurses.so.5 (0x00007ff1709d6000)
>         libdl.so.2 => /lib/libdl.so.2 (0x00007ff1707d2000)
>         libhdf5-1.6.5.so.0 => /usr/lib/libhdf5-1.6.5.so.0 (0x00007ff1704bb000)
>
>         libz.so.1 => /usr/lib/libz.so.1 (0x00007ff1702a4000)
>         libgfortran.so.2 => /usr/lib/libgfortran.so.2 (0x00007ff16ffe5000)
>         libm.so.6 => /lib/libm.so.6 (0x00007ff16fd64000)
>         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007ff16fa59000)
>
>         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007ff16f84b000)
>         libc.so.6 => /lib/libc.so.6 (0x00007ff16f4e9000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x00007ff16f2cd000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007ff174669000)
>
> I also have atlas libraries installed but it does not seem to use it correct?
>

Yes, it seems not to.

>
> Should I recompile it to use the atlas3 libraries?
>

"Should" is up to you. Compiling with a fast BLAS/LAPACK (personally, I recommend GotoBLAS if you qualify for the free license), will give you a significant speed-up, especially if you allow multithreading in BLAS. Also, when you compile, you probaly should get something newer than 3.0.0 - the latest stable snapshot from 3.0.x is 3.0.3 with a lot of fixes, and we're steadily striving towards 3.2.0, which should bring many new features, including significant performance improvements. Many of those are already available in the development version.
Be warned, however, that although compiling Octave itself is relatively easy, setting up all the libraries may be a tedious task. Though Octave should compile without any of them, you'll lose a lot of features if you don't use them. So the decision is up to you, but better be ready for issues if you want to compile Octave yourself.

> I do not think is a multiple core issue. My machine has 2 core, even if matlab used it it could be maximum a factor 2 of speed not a factor  7.
>

What BLAS library does your Matlab use? If it's something like ACML or MKL, I'd bet it exploits (or can exploit) your 2 processors. The only way is to check, of course. But the key point is that probably it uses a faster BLAS, whether multithreaded or not.

>
>
> Bytheway  the version is the one shipped with Ubuntu 8.04:
>

Blame it on Ubuntu, then :)

> octave --version
> GNU Octave, version 3.0.0
> Copyright (C) 2007 John W. Eaton and others.
> This is free software; see the source code for copying conditions.
>
> There is ABSOLUTELY NO WARRANTY; not even for MERCHANTIBILITY or
> FITNESS FOR A PARTICULAR PURPOSE.
>
> Octave was configured for "x86_64-pc-linux-gnu".
>
> Additional information about Octave is available at http://www.octave.org.
>
>
> Please contribute if you find this software useful.
> For more information, visit http://www.octave.org/help-wanted.html
>
> Report bugs to address@hidden> (but first, please read
>
> http://www.octave.org/bugs.html to learn how to write a helpful report).
>
> Cheers
> Luca
>
>
> On Thu, Oct 30, 2008 at 4:47 PM, Jaroslav Hajek address@hidden> wrote:
>
>
> On Thu, Oct 30, 2008 at 7:01 AM, Luca Tagliacozzo
>
> address@hidden> wrote:
>
> > Hello, I was wondering what  I am doing wrong:
>
> >
>
> > I was planning to pass some matlab programs to octave but as I will have to
>
> > do real simulation I was planning to write them in C++.
>
> >
>
> > Before starting the project I decided to make a simple test.
>
> >
>
> > I took the DaCoda example of the matpow.m file, did the esteatical changes
>
> > such that it can be run on matlab,
>
> >
>
> > and I run it on matlab via the following script: test.m
>
> >
>
> >
>
> > a=matpow(rand(1000),10);
>
> >
>
> >
>
> > That is it mutliplies log_2(10) times  a 1000x1000 matrix
>
> >
>
> > By running
>
> > time matlab -nodisplay
> >
>
> >
>
> > I get     0m4.076s as a user time
>
> >
>
> > we see that it take 4.076s to execute on my already fully loaded machine.
>
> >
>
> > Now always with the matpow.m file i did the following test:
>
> >
>
> > time octave test.m: user    0m21.189s
>
> > where we see that Octave took 21.189 seconds  (like 7 times matlab)
>
> >
>
> > Till here nothing strange since I was exectuing the matpow.m file.
>
> > Now I compile the matpow.cc and I crosscheck that octave sees it:
>
> >
>
> >
>
> > octave:1> help matpow
>
> > Return b = a^n for square matrix a, and non-negative, integral
>
> > n./home/luca/Desktop/testing_perf/matpow.oct
>
> > ......
>
> >
>
> > where we see that indeed it does see it in
>
> > /home/luca/Desktop/testing_perf/matpow.oct
>
> >
>
> > So now I run again the test: and we see that the the time is now 20.161s
>
> > very slight variation with respect to the non compiled case.
>
> >
>
> >
>
> > I thought it could be a matter of overload taken by octave to startup so I
>
> > decided to increase the matrix size to 3000x3000 where we would expect that
>
> > this should run for around 10 minutes so that the starting overhead should
>
> > be negligible
>
> >
>
> >
>
> >
>
> >
>
> > By running the .m file with matlab I get: 1m3.564s
>
> >
>
> > By running the .oct file with octave I get: a user time 8m59.474s
>
> >
>
> > By running the .m file with octave I get: 8m58.702s
>
> >
>
> >
>
> >
>
> > So I do not get any increase of performance by compiling the matlab
>
> > matpow.cc .
>
> >
>
> >
>
> > What am I missing?
>
>
>
>
>
>
>
> What Octave version do you use? How is it configured?
>
> The speed of large matrix multiplication is basically all about what
>
> BLAS library you use. If Octave doesn't find a suitable BLAS library,
>
> it will compile a simplistic one for you, but depending on what
>
> Fortran compiler you use, the compiled thing's speed may range from "a
>
> little slow" to "really slow". Also, chances are that your Matlab's
>
> BLAS is exploiting multiple cores, if you have a multi-core machine.
>
>
>
> --
>
> RNDr. Jaroslav Hajek
>
> computing expert
>
> Aeronautical Research and Test Institute (VZLU)
>
> Prague, Czech Republic
>
> url: www.highegg.matfyz.cz
>
>
>
>
reply via email to

[Prev in Thread] Current Thread [Next in Thread]