Параллелизм и оптимизация с использованием OpenMP

Question

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

Мой внутренний цикл:

    #pragma omp parallel for
    for(unsigned long j = 0; j < c_numberOfElements; ++j)
    {
        //int th_id = omp_get_thread_num();
        //printf("thread %d, j = %d\n", th_id, (int)j);

        Point3D current;
        #pragma omp critical
        {
            current = _points[j];
        }

        Point3D next = getNext(current);

        if (!hasConstraint(next))
        {
            continue;
        }

        #pragma omp critical
        {
            _points[j] = next;
        }
    }

_points - это pointMap_t, определяемый как:

typedef boost::unordered_map<unsigned long, Point3D> pointMap_t;

Без OpenMP мое время работы составляет 44,904 с.С включенным OpenMP на компьютере с двумя ядрами это 64,224 с.Что я делаю не так?

Answer 1

Почему вы завернули чтение и запись в _points[j] в критических разделах?Я не большой программист на C ++, но мне не кажется, что вам вообще нужны эти разделы.Как вы уже написали (критические разделы без названия), каждый поток будет ждать, пока другой пройдет через каждый из разделов.Это может легко замедлить работу программы.

Answer 2

Я согласен, что было бы лучше увидеть какой-нибудь рабочий код.

Главная проблема здесь заключается в том, что в параллельном регионе существуют критические элементы, и (а) они очень дорогостоящие и(б) по определению убить параллелизм.Присвоение текущему определению не обязательно должно быть внутри критического, поскольку оно является частным;Я бы не подумал, что назначение _points [j] тоже будет, но я не знаю, что делает карта, так что вы идете.

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

Answer 3

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

Если вам действительно нужно использовать контейнеры, рассмотрите возможность использования контейнеров из библиотеки Thread Building Blocks.

Answer 4

Возможно, что поиск и запись в _points в критических разделах снижает производительность при использовании OpenMP. Однопоточный, это не приведет к конфликту.

Совместное использование таких исходных данных в контексте параллельного программирования кажется контрпродуктивным. Можете ли вы реструктурировать, чтобы избежать этих спорных моментов?