Как бороться с error: invalid controlling predicate?

Question

[Морс Суперберг]

Добрый день! Столкнулся с проблемой при использование OpenMP.

Код подобной структуры:

int g(int x, int y){
         return y * x * y * x * 228;
    }

    int check(int x, int y){
       int c = g(x, y); 
       return x + y + c;
    }

    #pragma omp parllel
    {
        #pragma omp for
        for (int y = 5; y != 1920; y++) {
            for (int x = 5; x != 1080; x++) {                
                similarity += check(x, y);
            }
        }
    }

при компиляции выдается ошибка error: invalid controlling predicate, как с ней бороться? Спасибо.

Answer 1

[15432]

#pragma omp parllel

у вас ошибка в слове parallel

кстати, можно сразу написать

#pragma omp parallel for

Comments

[Морс Суперберг]

Сорри, это ошибка когда перепечатывал вопрос, в коде правильно написано

[15432]

NooooN, окей, тогда замените
!=
на
<

[15432]

еще одно замечание, пример для OpenMP не очень удачный, потоки будут делить между собой одну и ту же переменную similarity, по-хорошему нужно добавить прагму reduction:

#pragma omp parallel for reduction(+:similarity)
for (int y = 5; y < 1920; y++) 
{
    for (int x = 5; x < 1080; x++) 
    {                
        similarity += check(x, y);
    }
}

и те две мелкие функции сделать инлайнами, очень уж они простые чтоб на них два call тратить

[Морс Суперберг]

15432, заменил, на < появились ошибки

undefined reference to `GOMP_parallel'
undefined reference to `omp_get_num_threads'
..

[15432]

NooooN, а тут надо в настройки линковщика прописать подключение библиотеки openmp

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

#pragma omp parallel for reduction(+:similarity)
for (int y = 5; y < 1920; y++) 
{
    int local_sim = 0;
    for (int x = 5; x < 1080; x++) 
    {     
        local_sim += check(x, y);
    }
    similarity += local_sim;
}

прагма reduction (+) суммирует все значения с параллельных потоков в указанную переменную после их завершения

[Морс Суперберг]

15432, -fopenmp прописано, с переменной щяс попробую

[15432]

Если не надоел, то вот ещё вброс:

насколько я понял, вы оцениваете схожесть кадров видео. Но попиксельная разница - идея не самая оптимальная. Небольшое движение в кадре и усё, огроменная разница.

В своём проекте я использовал фильтрованную разницу гистограмм яркости. Принцип около такого:

- делим кадр на 64*64 блока (это позволит сравнивать даже кадры разного разрешения)
- переводим RGB в яркость (гуглите YUV color space, нужен только Y)
- считаем среднее значение яркости для каждого из блоков (среднее арифметическое годится)
- уря, получили нечто типа гистограммы для конкретного кадра

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

[15432]

Опять не уверен, но если подключаете сишный OpenMP в плюсовый проект, может понадобиться обернуть все #include в extern "C" {}
Если в линкере все настроено верно, то проблема в этом

[Морс Суперберг]

15432, огонь! Но у меня немного другая задача) можем списаться на почте?

[Морс Суперберг]

15432, я у меня так g++ ... ... -fopenmp больше ничего нет :)

[Морс Суперберг]

15432, все скомпилилось, но не знаю насколько параллельно, щяс буду проверять

[15432]

NooooN, на почту пишите, контакты в профиле :) правда я обработку 3D видео подзабросил, в ассемблер и железо ушёл.

[15432]

Ещё один небольшой вброс:

Оптимальнее внешний цикл делать по столбцам картинки (0..1080), а внутренний - по строкам (0..1920), поскольку соседние пиксели в строке расположены в памяти друг за другом, а вот соседние по столбцу друг от друга далеко. Постоянный проход по столбцам будет сильно дергать кеш и замедлять работу. А вот проход по строкам в самом глубоком цикле наоборот будет использовать рядом лежащие данные и целиком попадет в быстрый кеш.

[Морс Суперберг]

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

[15432]

неправильное значение вполне возможно из-за лажи с присвоением similarity.
попробуйте обернуть его в pragma omp critical (уберет все преимущества omp, но хоть проверите что дело в этом)

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

Хм, только заметил, что y идёт до 1920. Если у вас вертикальная ориентация экрана и 1080 это ширина экрана, то в коде всё верно.

[Морс Суперберг]

15432,

#pragma omp parallel for reduction(+:similarity){
#pragma omp critical{
for (int y = 5; y < 1920; y++) 
{
    int local_sim = 0;
    for (int x = 5; x < 1080; x++) 
    {     
        local_sim += check(x, y);
    }
    similarity += local_sim;
}
}
}

Вот так вы имели ввиду?

[15432]

типа этого. но код по мне выглядит нормально

#pragma omp parallel for reduction(+:similarity){
for (int y = 5; y < 1920; y++) 
{
    int local_sim = 0;
    for (int x = 5; x < 1080; x++) 
    {     
        local_sim += check(x, y);
    }
    #pragma omp critical{
        similarity += local_sim;
    }
}
}

просто для интереса можно попробовать распараллелить ещё и внутренний

#pragma omp parallel for reduction(+:similarity)
for (int y = 5; y < 1920; y++) 
{
    int local_sim = 0;
    #pragma omp parallel for reduction(+:local_sim)
    for (int x = 5; x < 1080; x++) 
    {     
        local_sim += check(x, y);
    }
    similarity += local_sim;
}

[Морс Суперберг]

15432, так тогда же не будет параллельности, нет разве? Нужно будет на каждый цикл разное количество ядер вешать

[Морс Суперберг]

#pragma omp parallel for reduction(+:similarity){
for (int y = 5; y < 1920; y++) 
{
    int local_sim = 0;
    for (int x = 5; x < 1080; x++) 
    {     
        local_sim += check(x, y);
    }
    #pragma omp critical{
        similarity += local_sim;
    }
}
}

Тоже бред выдает :(

[15432]

NooooN, уберите прагмы вообще, если и без параллельности бред получится, дело не в OMP

[Морс Суперберг]

15432,

#pragma omp parallel for reduction(+:similarity){

for (int y = 5; y < 1920; y++) 
{
    for (int x = 5; x < 1080; x++) 
    {                
        similarity += check(x, y);
    }
}

}

вот этот, код работает также как и без прагмы, по времени одинаково 24 секунды

[Морс Суперберг]

15432,

#pragma omp parallel for reduction(+:similarity){
for (int y = 5; y < 1920; y++) 
{
    int local_sim = 0;
    for (int x = 5; x < 1080; x++) 
    {     
        local_sim += check(x, y);
    }
    similarity += local_sim;
}
}

Это пофиксил, там вместо Инта local_sim - double, из за этого бред был. Но время все равно одинаковое. 24 секунды. И не бред и не параллелит.

[15432]

NooooN, как я писал ранее, наиболее медленной частью могли оказаться не вычисления, а доступ к памяти.
попробуйте поменять местами проход по x и y (то что я про кеш писал), посмотрите на загрузку проца в эти 24 секунды (без OMP на четырехъядерном проце будет загрузка 25%, с OMP будет больше 25%), посмотрите на сколько ядер OMP реально его параллелит (omp_get_num_threads()), попробуйте параллелить оба цикла (показывал ранее)

[Морс Суперберг]

15432, добился того что без прагмы 27 сек, с прагмой 24

[15432]

NooooN, мда. похоже OMP здесь вам сильно не поможет.

[Морс Суперберг]

15432, мне не особо вериться что 3 ядра всего лишь на 3 секунды ускорили

[Морс Суперберг]

15432, а как обращение к памяти ускорить?

[15432]

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

[Морс Суперберг]

15432, пока что своя машина Ubuntu 16.04