c++ - software - libreria armadillo

¿Es seguro el hilo resolver armadillo()?

Question

En mi código tengo un bucle en el que construyo y sobre determinado sistema lineal y trato de resolverlo:

#pragma omp parallel for
for (int i = 0; i < n[0]+1; i++) {
    for (int j = 0; j < n[1]+1; j++) {
        for (int k = 0; k < n[2]+1; k++) {
            arma::mat A(max_points, 2);
            arma::mat y(max_points, 1);
            // initialize A and y

            arma::vec solution = solve(A,y);
        }
    }
}

A veces, al azar, el programa se cuelga o los resultados en el vector de solución son NaN. Y si pongo haz esto:

arma::vec solution;
#pragma omp critical 
{
    solution = solve(weights*A,weights*y);
}

entonces estos problemas ya no parecen suceder.

Cuando se cuelga, lo hace porque algunos hilos están esperando en la barrera de OpenMP:

Thread 2 (Thread 0x7fe4325a5700 (LWP 39839)):
#0  0x00007fe44d3c2084 in gomp_team_barrier_wait_end () from /usr/lib64/gcc-4.9.2/lib64/gcc/x86_64-redhat-linux-gnu/4.9.2/libgomp.so.1
#1  0x00007fe44d3bf8c2 in gomp_thread_start () at ../.././libgomp/team.c:118
#2  0x0000003f64607851 in start_thread () from /lib64/libpthread.so.0
#3  0x0000003f642e890d in clone () from /lib64/libc.so.6

Y los otros hilos están atrapados dentro de Armadillo:

Thread 1 (Thread 0x7fe44afe2e60 (LWP 39800)):
#0  0x0000003ee541f748 in dscal_ () from /usr/lib64/libblas.so.3
#1  0x00007fe44c0d3666 in dlarfp_ () from /usr/lib64/atlas/liblapack.so.3
#2  0x00007fe44c058736 in dgelq2_ () from /usr/lib64/atlas/liblapack.so.3
#3  0x00007fe44c058ad9 in dgelqf_ () from /usr/lib64/atlas/liblapack.so.3
#4  0x00007fe44c059a32 in dgels_ () from /usr/lib64/atlas/liblapack.so.3
#5  0x00007fe44f09fb3d in bool arma::auxlib::solve_ud<double, arma::Glue<arma::Mat<double>, arma::Mat<double>, arma::glue_times> >(arma::Mat<double>&, arma::Mat<double>&, arma::Base<double, arma::Glue<arma::Mat<double>, arma::Mat<double>, arma::glue_times> > const&) () at /usr/include/armadillo_bits/lapack_wrapper.hpp:677
#6  0x00007fe44f0a0f87 in arma::Col<double>::Col<arma::Glue<arma::Glue<arma::Mat<double>, arma::Mat<double>, arma::glue_times>, arma::Glue<arma::Mat<double>, arma::Mat<double>, arma::glue_times>, arma::glue_solve> >(arma::Base<double, arma::Glue<arma::Glue<arma::Mat<double>, arma::Mat<double>, arma::glue_times>, arma::Glue<arma::Mat<double>, arma::Mat<double>, arma::glue_times>, arma::glue_solve> > const&) ()
at /usr/include/armadillo_bits/glue_solve_meat.hpp:39

Como puede ver en el stacktrace, mi versión de Armadillo usa atlas. Y de acuerdo con esta documentación, el atlas parece ser seguro para subprocesos: ftp://lsec.cc.ac.cn/netlib/atlas/faq.html#tsafe

Actualización 9/11/2015

Finalmente obtuve algo de tiempo para realizar más pruebas, según las sugerencias de Vladimir F.

Cuando compilo armadillo con BLAS de ATLAS, todavía puedo reproducir y luego cuelga y los NaN. Cuando se cuelga, lo único que cambia en el stacktrace es la llamada a BLAS:

#0  0x0000003fa8054718 in ATL_dscal_xp1yp0aXbX@plt () from /usr/lib64/atlas/libatlas.so.3
#1  0x0000003fb05e7666 in dlarfp_ () from /usr/lib64/atlas/liblapack.so.3
#2  0x0000003fb0576a61 in dgeqr2_ () from /usr/lib64/atlas/liblapack.so.3
#3  0x0000003fb0576e06 in dgeqrf_ () from /usr/lib64/atlas/liblapack.so.3
#4  0x0000003fb056d7d1 in dgels_ () from /usr/lib64/atlas/liblapack.so.3
#5  0x00007ff8f3de4c34 in void arma::lapack::gels<double>(char*, int*, int*, int*, double*, int*, double*, int*, double*, int*, int*) () at /usr/include/armadillo_bits/lapack_wrapper.hpp:677
#6  0x00007ff8f3de1787 in bool arma::auxlib::solve_od<double, arma::Glue<arma::Mat<double>, arma::Mat<double>, arma::glue_times> >(arma::Mat<double>&, arma::Mat<double>&, arma::Base<double, arma::Glue<arma::Mat<double>, arma::Mat<double>, arma::glue_times> > const&) () at /usr/include/armadillo_bits/auxlib_meat.hpp:3434

Compilando sin ATLAS, solo con netlib BLAS y LAPACK, pude reproducir los NaN pero no los bloqueos.

En ambos casos, rodeando solve() con #pragma omp crítico no tengo ningún problema

Answer 1

¿Estás seguro de que tus sistemas están sobre determinados? solve_ud en su seguimiento de pila dice lo contrario. Aunque también tiene solve_od , y probablemente eso no tenga nada que ver con el problema. Pero no está de más descubrir por qué sucede eso y arreglarlo si crees que los sistemas deberían ser extraños.

¿Es seguro el hilo resolver armadillo ()?

Eso creo que depende de su versión lapack, también vea this . Mirando el code de solve_od todas las variables a las que se accede parecen ser locales. Tenga en cuenta la advertencia en el código:

NOTA: la función dgels () en la biblioteca lapack suministrada por ATLAS 3.6 parece tener problemas

Por lo tanto, parece que solo lapack::gels puede causarle problemas. Si no es posible arreglar lapack, una solución alternativa es apilar sus sistemas y resolver un solo sistema grande. Eso probablemente sería aún más eficiente si sus sistemas individuales son pequeños.

Answer 2

La seguridad de subprocesos de la función solve() de Armadillo depende (solo) de la biblioteca BLAS que utilice. Las implementaciones de LAPACK son seguras para subprocesos cuando BLAS lo es. La función solve() Armadillo no es segura para subprocesos cuando se vincula a la biblioteca BLAS de referencia . Sin embargo, es seguro para subprocesos cuando se utiliza OpenBLAS . Además, ATLAS proporciona una implementación BLAS que también menciona que es seguro para subprocesos , y el Intel MKL también es seguro para subprocesos , pero no tengo experiencia con Armadillo vinculado a esas bibliotecas.

Por supuesto, esto solo se aplica cuando ejecuta solve() desde múltiples hilos con diferentes datos.