OpenMP: прагма отменить для ON NUMA

Question

--------------------- EDIT ------------------ -------

Я редактировал код следующим образом:

#pragma omp parallel for private(i, piold, err) shared(threshold_err) reduction(+:pi) schedule (static) 
{ 
    for (i = 0; i < 10000000000; i++){ //1000000000//705035067 
     piold = pi; 
     pi += (((i&1) == false) ? 1.0 : -1.0)/(2*i+1); 
     err = fabs(pi-piold); 
     if (err < threshold_err){ 
#pragma omp cancel for 
     } 

    } 
} 
    pi = 4*pi; 

я скомпилировать его с LLVM3.9/Clang4.0. Когда я запускаю его с помощью одного потока, я получаю ожидаемые результаты с действием отмены прагмы (проверяется на вариант отмены без прагмы, что приводит к более быстрому запуску).

Но когда я запускаю его с потоками> = 2, программа переходит в цикл. Я запускаю код на машинах NUMA. Что происходит? Возможно, условие отмены не выполняется! Но тогда код занимает больше времени, чем однопоточная версия без прагмы-отмены! FYI, он запускает файл, когда OMP_CANCELLATION = false.

---

У меня есть код OpenMP. Я использую LLVM-3.9/Clang-4.0 для компиляции этого кода.

#pragma omp parallel private(i, piold, err) shared(pi, threshold_err) 
{ 
#pragma omp for reduction(+:pi) schedule (static) 
    for (i = 0; i < 10000000 ; i++){ 
     piold = pi; 
     pi += (((i&1) == false) ? 1.0 : -1.0)/(2*i+1); 
     #pragma omp critical 
     { 
     err = fabs(pi-piold);// printf("Err: %0.11f\n", err); 
     } 
     if (err < threshold_err){ 
       printf("Cancelling!\n"); 
       #pragma omp cancel for 
     } 

    } 
} 

К сожалению, я не думаю, что #pragma omp cancel for завершает весь цикл for. Я печатаю значение err в конце, но опять же с параллелизмом он вводит в заблуждение, какое значение печатается. Конечное значение err меньше, чем threshold_err. Отмена печати печатается, но в самом начале программы, что удивительно. После этого программа продолжает работать!

Как убедиться, что это правильная реализация? BTW OMP_CANCELLATION устанавливается в true, а небольшая программа-тест возвращает «1» для соответствующей функции omp_get_cancellation().

Answer 1

Я понимаю, что omp cancel - это просто сигнал прерывания, он уведомляет об этом, чтобы нить не создавалось позже. Потоки, которые все еще работают, будут продолжаться до конца. См. http://bisqwit.iki.fi/story/howto/openmp/ и http://jakascorner.com/blog/2016/08/omp-cancel.html

Фактически, на мой взгляд, я считаю приемлемым приближение вашего программного продукта. Однако некоторые переменные могут сохраняться в меньших масштабах. Это мое предложение

#include <iostream> 
#include <cmath> 
#include <iomanip> 

int main() { 

    long double pi = 0.0; 
    long double threshold_err = 1e-7; 
    int cancelFre = 0; 

#pragma omp parallel shared(pi, threshold_err, cancelFre) 
    { 
#pragma omp for reduction(+:pi) schedule (static) 
     for (int i = 0; i < 100000000; i++){ 
      long double piold = pi; 
      pi += (((i&1) == false) ? 1.0 : -1.0)/(2*i+1); 
      long double err = std::fabs(pi-piold); 
      if (err < threshold_err){ 

#pragma omp cancel for 
       cancelFre++; 
      } 

     } 
    } 

    std::cout << std::setprecision(10) << pi * 4 << " " << cancelFre; 

    return 0; 
} 

Answer 2

Хорошо, поэтому я решил. В моем коде выше проблемы здесь:

err = fabs(pi-piold);

В строке выше pi изменяется до следующих, если состояние изменяется. Также несколько потоков делают то же самое. Насколько я понимаю, программа заходит в тупик.

я решил ее, заставляя только один поток, мастер, чтобы сделать эту проверку:

if(omp_get_thread_num()==0){ 
err = fabs(pi-piold); 
if (err < threshold_err){ 
#pragma omp cancel for 
     } 
} 

Я мог бы использовать #pragma omp single но это дало ошибку о вложенных прагмах.

Здесь производительность страдает от небольшого количества потоков (1-4 хуже, чем обычный последовательный код). После этого производительность улучшается. Это не лучшее решение, и кто-то наверняка улучшит это.