Блог

const LONGLONG UPPER = 1000000000; В моем коде есть a, и я пытаюсь вычислить сумму всех чисел от 1 до UPPER (да, я знаю, что для этого есть формула).

Это мои глобальные переменные:

 const LONGLONG UPPER = 1000000000;
const int NUM = 10; // number of threads
LONGLONG g_sum;
CRITICAL_SECTION cs_sum;
  

Это моя функция потока:

 DWORD WINAPI SumThread(PVOID pvParam) {
    LONGLONG i;
    LONGLONG sum = 0;
    LONGLONG x = (LONGLONG)pvParam;

    x = x * (UPPER / NUM);

    for (i = x   1; i <= x   UPPER / NUM; i  ) {
        sum  = i;
    }

    EnterCriticalSection(amp;cs_sum);
    g_sum  = sum;
    LeaveCriticalSection(amp;cs_sum);

    return 0;
}
  

И это код, который я использую для выполнения вычислений:

 HANDLE* hThreads = (HANDLE*)(malloc(sizeof(HANDLE) * NUM));
g_sum = 0;

InitializeCriticalSection(amp;cs_sum);
for (i = 0; i < NUM; i  ) {
    hThreads[i] = CreateThread(NULL, 0, SumThread, (PVOID)i, 0, NULL);
}

WaitForMultipleObjects(NUM, hThreads, TRUE, INFINITE);
DeleteCriticalSection(amp;cs_sum);
  

Но я получаю странные результаты: когда я суммирую числа в простом (последовательном) for цикле, это в два раза быстрее, чем многопоточная версия. Когда я умножаю UPPER на 10 и увеличиваю количество потоков до 40, многопоточная версия даже не останавливается (примерно через 20 минут). В чем причина этого?

Есть несколько вещей, которые представляют потенциальных виновников.

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

• Они очень хороши в оптимизации «циклов накопления», что вы и делаете в этом коде. Фактически, в зависимости от компилятора, они могут разворачивать цикл или использовать операции SIMD для ускорения всего процесса.
• Они не так хороши в оптимизации любого многопоточного кода, независимо от того, насколько прост код.

Я обнаружил аналогичные результаты при работе с однопоточными и многопоточными накопителями, и результаты обычно меняются (многопоточный код становится быстрее), когда оптимизация отключена.

В качестве примера рассмотрите возможность написания кода, который немного менее тривиален, чем «сложите все числа вместе между x и y «, и посмотрите, станет ли многопоточный код внезапно более эффективным. Я предсказываю, что так и будет, потому что компилятор потеряет способы оптимизации последовательного кода.

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

Последнее предложение — точно оценить, как вы выполняете вычисления. Если бы вы написали такой код:

 size_t sum = 0;
std::mutex mutex;
std::thread t1([amp;]{for(size_t i = 0; i < 1'000'000; i  ) {mutex.lock(); sum =i; mutex.unlock();}});
std::thread t2([amp;]{for(size_t i = 1'000'000; i < 2'000'000; i  ) {mutex.lock(); sum =i; mutex.unlock();}});
t1.join();
t2.join();
std::cout << "Sum of integers between 0 and 1999999: " << sum << std::endl;
  

Это почти наверняка будет медленнее, чем написанный вами код, который функционально идентичен:

 size_t sum = 0;
size_t s1 = 0, s2 = 0;
std::mutex mutex;
std::thread t1([amp;]{for(size_t i = 0; i < 1'000'000; i  ) {s1  = i;} mutex.lock(); sum  = s1; mutex.unlock();});
std::thread t2([amp;]{for(size_t i = 1'000'000; i < 2'000'000; i  ) {s2  = i;}mutex.lock(); sum  = s2; mutex.unlock();});
t1.join();
t2.join();
std::cout << "Sum of integers between 0 and 1999999: " << sum << std::endl;
  

Вы могли бы (акцент на слове «может») быть в состоянии получить незначительное ускорение, если вместо этого вы напишете это так (поскольку мьютексы / критические разделы обычно являются основными узкими местами в производительности):

 size_t sum = 0;
size_t s1 = 0, s2 = 0;
std::thread t1([amp;]{for(size_t i = 0; i < 1'000'000; i  ) {s1  = i;}});
std::thread t2([amp;]{for(size_t i = 1'000'000; i < 2'000'000; i  ) {s2  = i;}});
t1.join();
t2.join();
sum = s1   s2;
std::cout << "Sum of integers between 0 and 1999999: " << sum << std::endl;
  

Конечно, в данной ситуации это не является большой проблемой, но это всегда стоит учитывать и иметь в виду.

Буферизация потоков является дорогостоящей.

Я бы поспорил, что наибольшее влияние на время выполнения в этом случае оказывает оптимизация компилятора и прогнозирование ветвлений. оба из которых будут значительно лучше в последовательной версии в этом случае использования.

У вас есть несколько потоков, обращающихся к одному общему фрагменту памяти с блокировкой вокруг него. Все эти блокировки, разблокировки, переключение контекста, попадание в кэш и т. Д. Складываются во времени. Последовательный цикл в одном потоке не должен беспокоиться об этом.

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

Попробуйте что-то вроде этого:

 const LONGLONG UPPER = 1000000000;
const int NUM = 10; // number of threads

struct threadInfo
{
    LONGLONG start;
    LONGLONG sum;
};

DWORD WINAPI SumThread(PVOID pvParam) {
    struct threadInfo* pInfo = (struct threadInfo*) pvParam;
    LONGLONG i, sum = 0, x = pInfo->start;

    x *= (UPPER / NUM);

    for (i = x   1; i <= x   UPPER / NUM;   i) {
        sum  = i;
    }

    pInfo->sum = sum;
    return 0;
}

struct threadInfo* pInfo = (struct threadInfo*) malloc (sizeof(struct threadInfo) * NUM);

HANDLE* hThreads = (HANDLE*) malloc(sizeof(HANDLE) * NUM);

for (int i = 0; i < NUM;   i) {
    pInfo[i].start = i;
    hThreads[i] = CreateThread(NULL, 0, SumThread, amp;pInfo[i], 0, NULL);
}

WaitForMultipleObjects(NUM, hThreads, TRUE, INFINITE);

LONGLONG sum = 0;
for (int i = 0; i < NUM;   i) {
    sum  = pInfo[i].sum;
    CloseHandle(hThreads[i]);
}

free(pInfo);
free(hThreads);