Сокращение в Openmp возвращает разные результаты с тем же числом потоков в моем коде

Question

Мой код с openmp с использованием «сокращения» не возвращает те же результаты от запуска до запуска.

Случай 1: с помощью "сокращения"

sum = 0; 
omp_set_num_threads(4); 
#pragma omp parallel for reduction(+:sum) 
for(ii = 0; ii < 100; i++) 
    sum = sum + func(ii); 

с FUNC (II) имеет побочные эффекты. Фактически, func (ii) использует другую функцию calcul(), которая может привести к условию гонки при параллельном выполнении. Я думаю, что функция calcul() может быть причиной этой проблемы. Тем не менее, я использую «критический», результаты всегда одни и те же, но это решение не подходит для производительности. Второй

Корпус: с помощью "критического"

sum = 0; 
#pragma omp parallel for 
for(ii = 0; ii < 100; i++) 
{ 
    #pragma omp critical 
    sum = sum + func(ii); 
} 

с FUNC (II) функции

func(int val) 
{ 
    read_file(val); 
    calcul(); /*calculate something from reading_file(val)*/ 
    return val_fin; 
} 

Пожалуйста, помогите мне решить это?

Большое спасибо!

Answer 1

Даже если все в коде верное, вы по-прежнему можете получить разные результаты от сокращения OpenMP из-за ассоциативности операций (дополнений). Чтобы иметь возможность воспроизвести тот же результат для заданного количества потоков, вам нужно реализовать сокращение самостоятельно, сохранив частичную сумму каждого потока в общем массиве. После параллельной области основной поток может добавить эти результаты. Этот подход подразумевает, что потоки всегда выполняют одинаковые итерации, то есть политику статического планирования.

Связанные вопрос: Order of execution in Reduction Operation in OpenMP

Answer 2

Причина, по которой вы получаете низкую производительность во втором случае, - это весь корпус цикла в critical, поэтому он не может фактически выполнять что-либо параллельно.

Поскольку вы говорите, что существуют некоторые условия гонки в функции calcul, подумайте о том, чтобы разместить раздел critical только на этой линии внутри func. Таким образом, файлы могут считываться параллельно (что может быть вводом-выводом, которое все равно замедляет ваше выполнение).

Если производительность по-прежнему оставляет желать лучшего, вам нужно будет изучить вложенную функцию calcul и попытаться определить условия гонки.

В принципе, вы хотите направить любые разделы critical вниз, насколько возможно, или полностью устранить их. Если дело доходит до очень простых обновлений для общих переменных, в некоторых случаях вместо этого вы можете использовать прагму OpenMP atomic, которая имеет лучшую производительность, но гораздо менее гибкая.