help-octave
[Top][All Lists]
Advanced

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

Re: question on parallel processing


From: Fredrik Lingvall
Subject: Re: question on parallel processing
Date: Thu, 19 Oct 2006 10:51:19 +0200
User-agent: Thunderbird 1.5.0.7 (X11/20061010)

Joshua Rigler wrote:
> Jurzitza, Dieter wrote:
>  > Dear listmembers, is there any way for octave to do a parallel
>  > processing (i. e. when multiplying matrices, start 4 lines processing
>  > in parallel on 4 cpus), and if so, is there a pointer to a RTFM some
>  > kind person could point me to? Many thanks in advance, take care
>  >
>  >
>  > Dieter Jurzitza
>
>
> Dieter,
>
> In order to speed up certain matrix operations on shared memory 
> multi-cpu systems, you can use ATLAS' posix threaded blas libraries 
> (libptcblas.a, libptf77blas.a, and libatlas.a) instead of the default 
> blas libraries.  You may be able to download these precompiled, or you 
> might have to compile them yourself...this email won't cover that 
> process, which can be a bit tedious if you have a non-standard system.
>
> If that all goes smoothly (BIG "if"), you should have threaded blas 
> libraries for both C and F77.  
You can also consider the GOTO BLAS lib:

    http://www.tacc.utexas.edu/resources/software/

It is know to be the fastest BLAS implementation and it also
has thread support. It is also fairly easy to compile (with auto
detection of the hardware you are using). Note, however, that
it does not have a GPL license.
> My notes are old, but they seem to agree 
> with the config.log file I found in my old Octave source code directory. 
>   My configure invocation appears to have been (should be all on one line):
>
>    ./configure --enable-shared --enable-dl --enable-lite-kernel 
> --with-blas=-lptcblas -lptf77blas -latlas -lpthread 
> --with-lapack=/usr/local/lib/liblapack.a
>
> You'll note that I had to link explicitly to my own lapack library too. 
>   This was because I forced the "-fPic" option when compiling lapack.a 
> in order to make it compatible with posix threads and the ATLAS 
> libraries.  Fedora, at the time, was compiling lapack with the "-fnoPic" 
> option by default.  Note also that this all assumes that your shiny new 
> threaded blas libraries are already in the dynamic linker's default 
> path, or you must append "LDFLAGS=-L/path/to/libs" to the command above. 
>   You might also be required to append "CPPFLAGS=-I/path/to/headers" so 
> the compiler can find the necessary .h files.
>
> Keep in mind that I did all of this well over a year ago, when the 2.9 
> snapshots were only a gleam in JWE's eyes.  FWIW, I have since migrated 
> to using the latest Octave and Octave-Forge packages available through 
> Fedora Extras, which are NOT compiled to link to parallel blas libraries 
> as far as I know.  

> The hassle of recompiling everything every time a new 
> version came out outweighed the improvements in performance I saw for 
> only a handful of Octave matrix operations.
I use a soft link to solve this issue.  For example,

ln -s /usr/local/lib/libgoto_banias-r1.02.so  /usr/local/lib/libBLAS.so

Then I just relink to a new version of the goto lib when it is
available. Hence
no need to recompile Octave.

If you perform many and/or large matrix operations then you can save a
substantial
amount of time by using a optimized threaded BLAS lib.

/Fredrik


reply via email to

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