OpenMP на легковесных участках кода

Я пока только разбираюсь с OpenMP.

Вижу пользу только если цикл с #pragma omp parallel for содержит достаточно тяжёлый код, тогда польза от параллельности перевешивает накладные расходы на многопоточность. Влияния количества повторов в цикле не заметил.

Однако здесь красиво так утверждается что код:

double parallel_max(double* A, int size)
{
    int maxval = INT_MIN;
    #pragma omp parallel for reduction(max : maxval)
    for (i = 0; i < size; ++i)
        if (A[i] > maxval) maxval = A[i];
    return maxval;
}

оптимизирует производительность.

По-быстрому слепил тест:

#ifndef NOMINMAX
    #define NOMINMAX    // отключить макросы min / max чтобы они не конфликтовали с std::min / std::max - нужен для opencl.hpp
#endif
// Файлы заголовков среды выполнения C
#include <stdlib.h>
#include <windows.h>
#include <iostream>
#include <fstream>
#include <vector>
#include <chrono> 
#include <thread>
#include <format>
#include <omp.h>

//------------------------------------------------------------------------------
// Заполнить вектор псевдослучайными числами в диапазоне от -max_rnd до max_rnd
template<typename Type>
void fill_rand(std::vector<Type> &A, Type max_rnd = 100)
{
    for (size_t i = 0; i < A.size(); i++)
            A[i] = static_cast<Type>(rand()) / static_cast <Type> (RAND_MAX / (2 * max_rnd)) - max_rnd;
};

//==============================================================================
int main()
{
    using namespace std::chrono;
    std::this_thread::sleep_for(100ms); // "Стабилизация" системы перед замером производительности

    time_point<steady_clock> time_start;
    long long time_min;     // минимальное время в серии тестовых замеров

    double maxval;
    size_t n = 100'000;
    std::vector<double> A(n);
    fill_rand(A);
        
    int n_tests = 1;
    time_min = std::numeric_limits<long long>::max();   // сбросить минимальное время перед новой серией замеров
    SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
    for (int i = 0; i < n_tests; i++)
    {
        time_start = steady_clock::now();
            maxval = -std::numeric_limits<double>::max();
//          #pragma omp parallel for reduction(max : maxval)
            for (size_t i = 0; i < A.size(); i++)
                if (A[i] > maxval) maxval = A[i];
        time_min = std::min(time_min, duration_cast<nanoseconds>(steady_clock::now() - time_start).count());
    };
    SetPriorityClass(GetCurrentProcess(), NORMAL_PRIORITY_CLASS);
    std::cout << std::format("n = {}, maxval = {:.2f},  time of test - {} ns.\n", n, maxval, time_min);

    system("pause");
    return 0;
};

И вижу, что при n = 100'000 и менее #pragma omp parallel for reduction(max : maxval) существенно так замедляет, а не ускоряет. При n = 100'000'000 что с #pragma omp, что без неё время одинаково (с поправкой на естественные колебания замеров).

И ни при каком n я не получил ускорения от OpenMP.

Это я чего-то не понимаю?

Или всё таки OpenMP даёт выигрыш только при распараллеливании тяжёлого функционала, а примеры от Microsoft фейковые?

Примеры замеров:

n = 100'000:

• 10'700 ns без #pragma omp
• 397'600 ns с #pragma omp - сильное замедление вместо ускорения

n = 100'000'000:

• ~30 милисекунд в обоих вариантах.

Естественно значения ориентировочные и "пляшут" при повторных запусках теста, однако порядок и соотношение стабильно такие.

Windows 10, компиляторы от msys2:

• clang с ключами -std=c++23 -O2 -mavx2 -fopenmp
• MinGW с ключами -std=c++23 -Ofast -march=x86-64-v3 -fopenmp