7

I am a novice using the LAPACK routines, so I don't deeply know them, and I want to use them in parallelized loops (openmp).

I use Ubuntu 14.04LTS and have LAPACK installed using my package manager. The version installed is:

liblapack3    3.5.0-2ubuntu1     Library of linear algebra routines 3 - shared version

The associated BLAS library is:

libblas3    1.2.20110419-7

So, my first question is quite simple: can I use any subroutine or function of the LAPACK in a loop parallelized using OpenMP?. Id est, are they thread safe?.

Another questions is: Can I use any subroutine or function of the LAPACK in my pure subroutine?, id est, in a subroutine coded by me and defined as pure.

If the answer to these questions are "not with all LAPACK procedures but with some of them", then, can I do it with the following subroutines?:

  • dgetrs
  • dgetrf
  • dgetri
  • dgecon

And one last question: Do the LAPACK procedures use all my cores?, id est, are they already parallel?.

ztik
  • 3,482
  • 16
  • 34
Antonio Serrano
  • 385
  • 2
  • 15

2 Answers2

10

The LAPACK library is expected to be thread safe. It does not support multiple threads, so it does not use (all) your systems cores. Actually there is a specific declaration that all LAPACK subroutines are thread-safe since v3.3.

On the other hand LAPACK is designed to use extensively BLAS library subroutines. The basic BLAS does not use any threads either. However there are several popular BLAS implementations (ATLAS, OpenBLAS, MKL) which have threaded versions of most BLAS subroutines. If your LAPACK library is using one of the above BLAS libraries then it is quite possible that their subroutines will start their own threads. Of course, in the above libraries, the user can control the number of threads used. You can consult their documentation to find out the way.

So you need to check which implementation of the BLAS library you use in order to have clear view of LAPACK's thread usage.

Regarding the usage inside pure functions, I wish to note that both BLAS and LAPACK print specific error messages on the screen (stdout or stderr). These messages usually related on false usage of the subroutine and not mathematical errors. For example if you try to invert a zero dimension matrix. If you can secure this then probably you can say it is pure.

ztik
  • 3,482
  • 16
  • 34
  • 1
    And I can see that I cannot use them in a _pure_ function. I get the following error: `Error: Subroutine call to 'dgetrs' at (1) is not PURE` – Antonio Serrano Jun 19 '15 at 10:55
  • For reference: MKL provides interfaces for pure Fortran 95 subroutines https://software.intel.com/en-us/node/468670 – astrojuanlu Nov 25 '15 at 10:34
-1

Correct me if I am wrong, but I think that, in general, LAPACK subroutines are not pure. Not only because they print out messages, but because they use to return the result stored in the input variable. That is, for example, if you try to invert a matrix, the subroutine is something like inv(A), where A is the input and output at the same time (intent (inout)) instead of having inv(A,B) where A is only in, and B is only out.

They cannot be pure because they modify their inputs.

Manuel Pena
  • 304
  • 2
  • 11
  • 1
    Fortran has a concept of `pure` subroutines. They do modify their arguments, but that doesn't matter, the point is that they do not have side-effects. Modifying an output argument is not a side-effect, it is an effect which can be perfectly thread-safe. – Vladimir F Героям слава Jun 04 '18 at 11:29
  • 1
    Secondly, printing of messages is not `pure`, but that does not matter that they must be thread unsafe. This printing can be done in a `critical` section (using OpenMP, mutexes or whatever threading you use) and that will make it thread-safe. – Vladimir F Героям слава Jun 04 '18 at 11:31