Чи безпечно вирішувати нитки armadillo?


86

У моєму коді у мене є цикл, в якому я будую та визначаю лінійну систему і намагаюся її вирішити:

#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);
        }
    }
}

Іноді, досить випадково, програма зависає або результати у векторі розчину є NaN. І якщо я поставлю, зробіть це:

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

тоді ці проблеми більше не здаються.

Коли він зависає, він робить це, оскільки деякі потоки очікують на бар'єрі 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

А інші нитки застрягли всередині 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

Як ви можете бачити зі стеку, моя версія Armadillo використовує атлас. І згідно з цією документацією атлас здається безпечним для потоків: ftp://lsec.cc.ac.cn/netlib/atlas/faq.html#tsafe

Оновлення 9/11/2015

Нарешті я отримав трохи часу, щоб провести більше тестів на основі пропозицій Володимира Ф.

Коли я складаю armadillo з BLAS від ATLAS, я все ще можу відтворити, а потім зависання та NaN. Коли він зависає, єдине, що змінюється в стеці, - це виклик 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

Компілюючи без ATLAS, лише за допомогою netlib BLAS та LAPACK, я зміг відтворити NaN, але не зависання.

В обох випадках, оточуючи solve()з #pragmaOMP критичним У мене немає ніяких проблем взагалі


1
Чи є /usr/lib64/libblas.so.3 частиною атласу? Чому він не знаходиться в / usr / lib64 / atlas?
Володимир Ф

1
Ні, у opensuse це частина пакунка liblas3, а в червономухаті це частина пакета blas.
maxdebayser

2
Тоді ви не можете використовувати будь-які гарантії ATLAS, коли ви використовуєте BLAS за замовчуванням.
Володимир Ф

2
Ви вирішили це? Якщо ні, які пакети встановлені, і чи можете ви, будь ласка, опублікувати команду, яку використовували для компіляції програми?
vindvaki

3
Ви також можете спробувати використовувати OpenBLAS замість Atlas.
mtall

Відповіді:


2

Ви впевнені, що ваші системи вирішили більше? solve_udу вашому трасі стека говорить інакше. Хоча у вас solve_odтеж є , і, мабуть, це нічого спільного з проблемою не має. Але не завадить дізнатися, чому це відбувається, і виправити це, якщо ви вважаєте, що системи повинні бути одними.

Чи безпечно вирішувати нитки armadillo?

Те, що, на мою думку, залежить від вашої версії lapack, теж перевірте це . Дивлячись на код з solve_odусіх змінних , доступних здаються локальними. Зверніть увагу на попередження в коді:

ПРИМІТКА: функція dgels () у бібліотеці lapack, що постачається ATLAS 3.6, схоже, має проблеми

Таким чином, здається, це lapack::gelsможе лише створити для вас неприємності. Якщо виправити lapack неможливо, обхідним шляхом є складання ваших систем і вирішення однієї великої системи. Це, мабуть, було б ще ефективніше, якби ваші окремі системи мали невеликі розміри.


1

Безпека потоків функції Armadillo solve()залежить (лише) від бібліотеки BLAS, яку ви використовуєте. Реалізації LAPACK є потокобезпечними, коли BLAS є. Функція Armadillo неsolve() є безпечною для потоків під час посилання на посилальну бібліотеку BLAS . Однак це безпечно для потоку під час використання OpenBLAS . Крім того, ATLAS забезпечує реалізацію BLAS, яка також згадує, що вона безпечна для потоків , а також Intel MKL також є безпечною для потоків , але я не маю досвіду роботи з Armadillo, пов’язаним з цими бібліотеками.

Звичайно, це стосується лише запуску solve()з декількох потоків з різними даними.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.