Почему использование большего количества потоков приводит к замедлению времени выполнения? - PullRequest
Новая
       14

Почему использование большего количества потоков приводит к замедлению времени выполнения?

0 голосов
/ 14 октября 2019

Я использую Ubuntu на машине с 32 процессорами (1 сокет, 16 ядер на сокет, 2 потока на ядро).

У меня есть std :: vector, содержащий ~ 100-1000 объектов, и япытаясь распараллелить цикл for, который считывает данные из каждого объекта в векторе и записывает в файл для регистрации состояния каждого объекта. Существует один файл для каждого объекта. Я поиграл с omp_set_num_threads(8) и обнаружил, что есть приятное место из 8 потоков. Если я увеличу или уменьшу количество потоков, производительность во время выполнения снизится. Учитывая, что у меня 32 доступных процессора, я не уверен, почему увеличение числа потоков выше 8 снижает производительность во время выполнения. Я знаю, что многие подобные вопросы задавались ранее, но я не могу найти решение своей конкретной проблемы. 

#include <algorithm>
#include <experimental/filesystem>
#include <omp.h>
namespace fs = std::experimental::filesystem;  

void log() {
    omp_set_num_threads(8);

    // Log all object states
    if(this->logstate){
        #pragma omp parallel for
        for(auto i = vObject.begin(); i < vObject.end(); ++i)   {
            fs::path filename = (*i)->get_filename();
            std::ofstream OutputFile;
            OutputFile.open(filename, std::ios::app);
            OutputFile << std::setw(30) << (*i)->get_EPOCH() << std::setw(20) << std::scientific << std::setprecision(5) << (*i)->get_state() << std::endl;
            OutputFile.close();
        }
    }
}

Буду признателен за любые мысли или предложения.

1 Ответ

1 голос
/ 14 октября 2019

Я использую Ubuntu на компьютере с 32 процессорами (1 сокет, 16 ядер на сокет, 2 потока на ядро).

Поток не является процессором. Ядро даже не процессор;Каждое ядро ​​может выполнять код независимо, но все они совместно используют одну шину памяти и различные другие ресурсы.

Итак, у вас есть 32 потока, работающих на 16 ядрах, и все они используют одну шину. В какой-то момент будет конкуренция за то, и это означает, что многие из этих нитей должны сидеть и ждать. Больше потоков -> больше конфликтов -> больше ожиданий.

Теперь мы все можем сделать обоснованные предположения о том, где может быть конфликт ресурсов - это файловая система, шина памяти или что-то еще? Но мы мало знаем о вашей системе и о том, что еще может происходить, так что это, вероятно, бессмысленно. Профилирование вашего кода, работающего на большем количестве потоков, чтобы увидеть, где он ждет, может предложить некоторые ответы. Просто имейте в виду, что эти ответы могут быть специфическими для вашей текущей ситуации;если вы измените вычислительную работу, которую необходимо выполнить для каждого объекта, или измените способ сбора выходных данных и т. д., это, вероятно, повлияет на то, где находится «сладкое пятно».

...