LibFlame with Pthreads

[Anouar Benali]

Hi,

I am trying to use libflame with pthreads but I am having hard time figuring out how I can really do that.

I have a test code where I create my matrices and then simply call an LUfactorization with FLAME. If I want to use the threaded version with openmp, it is quiet simple; I do nothing and just run the code by setting omp_num_threads=X. But being new to posix threads coding, if I create the threads (with pthread_create) I basically call X times the same fuction (and I want X threads working on the same fuction).

Thanks again

Anouar Benali

[Field G. Van Zee]

Anouar,

It helps to understand WHAT pthreads vs. openmp support in libflame actually
does. (It may not be what you think.)

libflame supports shared memory parallelism at the algorithm level (LU,
Cholesky, QR, etc.) You can achieve this parallelism via pthreads or openmp,
but the basic mechanism in libflame is the same. In libflame, you always set
the number of threads that libflame uses via a function at runtime:

void FLASH_Queue_set_num_threads( n_threads );

rather than via environment variable. (Actually, there MIGHT be some support
for environment variables, but I don't recall as I was never in charge of
maintaining this part of libflame. But regardless, using the runtime API is
preferred.)

The above routine sets the number of threads that the SuperMatrix runtime
system will use. But, in order to actually invoke the multithreaded code, you
have to call the FLASH_*, rather than the FLA_*, routines. You can see an
example in:

src/base/flamec/supermatrix/test/lu/piv/driver_lu_piv.c

Now, notice that these are quite different APIs, since they inherently assume
storage by contiguous blocks (tiles), which may not be what you want. Usually,
what people want to do is just link an LAPACK-like routine to multithreaded
BLAS. libflame can do this, by linking to a multithreaded BLAS and calling the
regular FLA_* routines. However, this has nothing to do with pthreads vs.
openmp in libflame, because all of the parallelism in this scenario is derived
OUTSIDE of libflame, within the BLAS, and how the external BLAS implements its
parallelism is outside the scope of what libflame is concerned with.

Hopefully that helps.

Regards,
Field