Russian Qt Forum

Всем привет!

Скажите поддерживает ли minGW библиотеку openMP? вообще в папке minGW  есть opm.h и на сайте openmp написано что компилятор gcc (4.3.2) поддерживает данную библиотеку. А я как понимаю minGW это версия gcc под винду.

Если да, то как включить поддержку? На том же сайте написано "Compile with -fopenmp", но где прописать это мне не понятно. Может в файле *.pro проекта?

У меня Qt Creator 4.6.0 и виста.

P.S. VC2008 это сделать очень просто.

#include <omp.h>
#include <stdio.h>

int main(int argc, char **argv)
{
#if defined(_OPENMP) 
	printf("Compiled by an OpenMP-compliant implementation.\n"); 
	printf("The result of omp_get_num_threads %i\n", omp_get_num_threads());
#endif

    return 0;
}

CONFIG += console
TEMPLATE = app
TARGET = 
DEPENDPATH += .
INCLUDEPATH += .
QMAKE_LFLAGS += -fopenmp
SOURCES += example.cpp

В свойствах проекта нужно дописать (там, где QMake build arguments)

"QMAKE_LIBS+=-static -lgomp -lpthread" "QMAKE_CXXFLAGS+=-msse3 -fopenmp" QMAKE_CXXFLAGS+=-U_WIN32

Только почему-то у меня при вызове omp_get_num_threads() и вообще любых OpenMP функций не из main, а из потока QThread программа выпадает с ошибкой Segmentation Fault.

to zlogic
Огромное спасибо!!!! все работает!! :) И настроение улучилось больше чем прирост скорости счета :) Все таки человек очень нелинейная система  :)

to crackedmind
Спасибо за содействие, проделал данную процедуру, но она не работает, но зато я понял куда прописывать команды написанные zlogic!

Я рад :)

На самом деле можно сократить до
"QMAKE_LIBS+=-static -lgomp -lpthread" "QMAKE_CXXFLAGS+=-fopenmp"

Если будет выпадать с segmentation fault, это известный баг в gcc, описание тут:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42616
Пока что не исправлено :((

Может кто-нибудь, пожалуйста, подсказать, как в qt посмотреть версию поддерживаемой OpenMP или же можете просто написать ее?

Там в качестве компилятора gcc 4.4.0, а он в свою очередь поддерживает OpenMP 3.0

А вот я что-то не пойму, куда вставлять этот код.
Скриншот: http://slil.ru/28698022
Если пишу в кавычках - куда бы ни написал, никакой ошибки не возникает, но и OpenMP не работает.
Если пишу в Дополнительные параметры, то возникает ошибка
"***Unknown option -lgomp"
Если пишу в Параметры make, то возникает ошибка
"mingw32-make: openmp: No such file or directory
mingw32-make: *** No rule to make target `openmp'. Stop."

Кавычки обязательны, нужно писать все параметры в верхнюю строчку (Дополнительные Параметры во вкладке QMake).
И на скриншоте параметры make не обведены, но на самом деле там ничего не должно быть.
А как вообще определяется, что openmp не работает?

Я пытался проверить следующим образом:
#if defined(_OPENMP)
   printf("Compiled by an OpenMP-compliant implementation.\n");
   printf("The result of omp_get_num_threads %i\n", omp_get_num_threads());
#endif
и ни в каком случае это условие не срабатывало, хотя проект компилится и ошибок нет

Хм, странно, у меня нормально работает

А у кого-нибудь было такое, что после подключения OpenMP и прописывание #pragma omp parallel for программа компилируется, но после запуска сразу же завершает работу с кодом -1073741515? Я в интернете не нашел расшифровку этой ошибки. Если кто встречался, подскажите что делать

Там в сообщении где-нибудь есть sigsegv, segmentation fault, NULL или нечто подобное? Если есть - поздравляю, это не исправленный баг gcc.
Если нет, скорее всего в директории, откуда делается запуск, не хватает dll, должны быть
libgcc_s_dw2-1.dll
pthreadGC2.dll
и возможно
mingwm10.dll

Не, ничего такого нет. Просто пишет "Запускается приложение test.exe... test.exe завершился с кодом -1073741515" А где взять libgcc_s_dw2-1.dll?

C:\Qt\версия_qt\mingw\bin

Нет, это не та ошибка, про которую вы думаете. Стоит закомментить #pragmа omp parallel как все нормально работает

А это debug или release версия?

Все, спасибо всем, кто уделил мне время и помог разобраться. У меня все заработало

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

Разве?
А как можно без поддержки компилятора распараллелить цикл по нескольким потокам?
Насколько я представляю, QtConcurrent может выполнить функцию в отдельном потоке, но OpenMP предназначен для другого.
 

Эти 2 вещи "имеют нечто схожее" - но не более того. QtConcurrent::map может рассматриваться как аналог #pragma omp parallel for. Однако когда надо выжимать скорость - увы, результат совсем не в пользу QtConcurrent. Остальных возможностей QtConcurrent вообще не имеет, и нельзя его в этом обвинять, т.к. он не поддерживается компилятором. Напр. QuickSort реализуется на OpenMP, а с QtConcurrent не видно даже подходов. Что касается "реализации без импользования низкоуровневых примитивов" (как написано в документации) то это хорошо для простых случаев. Но если углубиться "чуть дальше в лес" то блокировки/синхронизации все равно возникают и придется использовать Qt мутексы и семафоры, которые заметно уступают OpenMP аналогам.

Для отдельного потока существует QThread, а QtConcurrent позволяет распараллеливать задачи по ядрам процессора, ну и тоже умеет создавать дополнительные потоки.

Хотелось бы посмотреть на пример реализации одной и той же задачи обоими способами. Я с OpenMP не работал, может выложит кто-нибудь сравнение с реальными цифрами? В чем проблема QuickSort одновременно запускать на двух ядрах? Для этого не нужна поддержка со стороны компилятора, достаточно функций, которые предоставляет ОС.

Разные задачи по разным потокам.
Но насколько мне известно, она не может распараллелить одну задачу на несколько ядер. Не?

Если имеется ввиду какая-то сложная формула, где нет циклов/итераций, массивов с индексами и эту формулу ну никак не разбить на несколько подзадач даже теоретически, то нет.

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

Поэтому, IMHO и нельзя сказать, что QtConcurrent и OpenMP делает тоже самое.  ;)

Я не нашел примеров на OpenMP, где бы не циклическая задача распараллеливалась по ядрам. Почти везде for(). Если OpenMP может распределить длинную портянку линейного кода без входных параметров по ядрам, то я бы хотел на это посмотреть. Если сравнивать многоядерность с конвеером процессора, то некоторые задачи просто физически никак не распараллелить, например если результат иснтрукции зависит от другой инструкции. В длинных формулах может быть как раз такая ситуация. Что не может распараллелить процессор - не может распараллелить и человек, будь у тебя хоть 100 ядер.

Конечно не сможет.
Я про это и говорю, что это два абсолютно разных подхода к распараллеливанию и сравнивать их, IMHO, никак нельзя.

Если OpenMP не сможет и QtConcurrent не сможет, а циклы оба смогут то какая разница?

В том что QuickSort алгоритм рекурсивный  :)

С удовольствием поддержу эту инициативу, мне сделать на OpenMP нетрудно. А вот реализация на QtConcurrent - это уж Ваша забота. Давайте определим задачу, число итераций и.т.п. Конечно, нужны разумные тестовые вычисления (без тонны специфики)

Никто не будет за программиста распараллеливать, но разница может быть очень ощутима. Если каждой нитке дается задача на секунды - то кто ж спорит, QtConcurrent использовать куда как приятнее. Но вот у меня "единица вычислений" миллисекунды и тут все "детали реализации" становятся очень важны. То же и с числом вычислений на цикл: если их там миллион - то любая реализация хороша. А вот если всего 100-200 - тогда с 2 процессорами можно получить медленнее чем с одним. Ну и конечно, цикл - далеко не все что есть в OpenMP.

Это как пила и топор - да, оба предназначены для заготовки дров. Но инструменты разные  :)

На сколько я знаю, то существуют варианты quicksort без рекурсии. В OpenMP используется рекурсивный вариант? Можно поискать реализацию без рекурсии и реализовать её в QtConcurrent, потом сравнить скорости рекурсивного варианта OpenMP и не рекурсивного в QtConcurrent.

Судя по статье (http://msdn.microsoft.com/en-us/magazine/cc163717.aspx) с сайта microsoft можно сделать следующие выводы. Реализация быстрой сортировки таким методом:

C++ (Qt)
void QuickSort (int numList[],  int nLower, int nUpper) 
   {
   if (nLower < nUpper)     
      {
      // create partitions
      int nSplit = Partition (numList, nLower, nUpper);
      #pragma omp parallel sections
      {
         #pragma omp section
         QuickSort (numList, nLower, nSplit - 1);
 
         #pragma omp section
         QuickSort (numList, nSplit + 1, nUpper);
      }
   }
}
 
 

создает 2 конкурентных потока. Это значит, что на машине с 8 ядрами задействованы будут только 2 из них. Разделение массива на 2 части это особенность алгоритма. Но есть еще вариант, который называется 3-way partition. Тут уже будет не один pivot (стержень, опорная точка), а 2. Теоретически можно сделать количество опорных точек равное количеству ядер минус 1. Естественно выгода будет только если массив большой длины. Задействовать 8 ядер для сортировки 16 элементов массива не рационально.

Тут поправьте меня, если я не прав. Первый вызов QuickSort() выполняется на одном ядре в том же потоке в котором и был запущен. Функция Partition() также выполняется на одном ядре. Разделение на конкурентные потоки происходит только после того как Partition() разделит массив на 2 части. С левой стороны числа меньшие или равные опорному значению, с правой стороны числа большие опорного значению. Тут происходит первый рекурсивный вызов, а точнее 2 вызова QuickSort, что аналогично запуску двух новых потоков. Дальнейшие рекурсивные вызовы происходят внутри независимых потоков. Я например не вижу никаких припятствий рекурсивного вызова функции находящейся в отдельном потоке. Почему бы для QtConcurrent это стало проблемой? Думаю проблем тут никаких нет.

Хороший плюс в пользу OpenMP это возможность переключение на стандартный алгоритм сортировки при отсутствии библиотеки OpenMP. То есть не нужно переписывать старый код. С вариантом использования QtConcurrent нужно делать рефакторинг.

Задачи, которые хотелось бы решить:
- реализовать X-Way partition алгоритм (как бы авторские права на патент (http://www.freepatentsonline.com/y2007/0088699.html) не нарушить), где X количество процессоров минус один.
- реализовать алгоритм поиска медианы в качестве опорного значения, чтобы распределить нагрузку на ядра и увеличить скорость сортировки. В стандартном варианте берется самый первый элемент массива в качестве опорного значения. Это означает, что из двух частей (левой и правой) одна часть может содержать 2 элемента, в то время как другая тысячу. Естественно, что при таком раскладе большую часть работы будет делать только одно ядро.
- переписать алгоритм, чтобы полностью отказаться от рекурсии. В худшем случае ограничить максимальную глубину рекурсии (level).

Какой бы алгоритм сортировки не был хороший все зависит от данных, которые будут располагаться в массиве. В самом худшем случае будет работать только одно ядро.
---
Нашел (http://alienryderflex.com/quicksort) безрекурсивный вариант, основанный только на вложенных циклах:

C++ (Qt)
//  quickSort
//
//  This public-domain C implementation by Darel Rex Finley.
//
//  * This function assumes it is called with valid parameters.
//
//  * Example calls:
//    quickSort(&myArray[0],5); // sorts elements 0, 1, 2, 3, and 4
//    quickSort(&myArray[3],5); // sorts elements 3, 4, 5, 6, and 7
 
#define MAX_LEVELS 300
 
void quickSort(int* arr, int elements)
{
    int piv;
    int beg[MAX_LEVELS];
    int end[MAX_LEVELS];
    int i = 0;
    int L;
    int R;
    int swap;
 
    beg[0] = 0;
    end[0] = elements;
 
    while (i >= 0) {
        L = beg[i];
        R = end[i]-1;
 
        if (L < R) {
            piv = arr[L];
            while (L < R) {
                while (arr[R] >= piv && L < R)
                    R--;
                if (L < R)
                    arr[L++] = arr[R];
 
                while (arr[L] <= piv && L < R)
                    L++;
                if (L < R)
                    arr[R--] = arr[L];
            }
 
            arr[L] = piv;
            beg[i+1] = L+1;
            end[i+1] = end[i];
            end[i++] = L;
 
            if (end[i]-beg[i] > end[i-1]-beg[i-1]) {
                swap = beg[i];
                beg[i] = beg[i-1];
                beg[i-1] = swap;
                swap = end[i];
                end[i] = end[i-1];
                end[i-1] = swap;
            }
        }
        else {
            i--; 
        }
    }
}
 
 

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

Мне нужна была балансировка kd-дерева, я скопировал по примеру QuickSort, откуда - не помню  :) Вот др. простой пример, техника та же самая http://www.openmp.org/pipermail/omp/2005/000145.html (http://www.openmp.org/pipermail/omp/2005/000145.html)

Все процессоры могут быть задействованы хотя да, нагрузка не перераспределяется. Да, первое деление выполняется на 1 ядре (в главной нитке), потом на 2-х рабочих нитках и.т.д. Разумно (и нужно) ограничить числом ядер.

Тут я Вас не понял. Ф-ции это просто код, одна и та же ф-ция может одновременно выполняться в разных нитках. "Задействовать" одну нитку из другой совсем не просто - надо как-то ей "дать задачу", ведь просто вызвать ф-цию - ну она в вызванной нитке и выполнится. Директивы task/taskq это делают, пусть нужна обвязка но это вполне приемлемо. Вместо этого брать следующую нитку из пула - резона нет, больше потеряется на запуске/останове.

Так вот именно, альтернативный алгоритм - удовольствие дорогое

Чего-то мы тут велосипед придумываем. Оказывается достаточно подключить openmp к программе и большинство стандартных алгоритмов начинают сами распараллеливаться: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch31s03.html

Только еще надо дефайн передать -D_GLIBCXX_PARALLEL и использовать другое наименование методов, "__gnu_parallel::sort" например.

P.S.: проголосовал (http://bugreports.qt.nokia.com/browse/QTBUG-3466) за предложение сделать распараллеленные версии алгоритмов Qt.

P.P.S.: прикольный ролик (http://www.zutopedia.com/auto/algorithm.html)-визуализатор двух алгоритмов Buble Sort и Quick Sort. Роботы сортируют :)

P.P.P.S: оказывается сортировка Radix быстрее (http://mgarland.org/files/papers/nvr-2008-001.pdf) на GPU, чем QuickSort.

Послушайте, кто-нибудь сталкивался с подобной задачей? В общем нужно реализовать параллельную задачу через OpenMp. Данные вводятся с формы, далее запускается рассчеты, при этом форма во время этих рассчетов не должна тормозить. Если просто написать подряд код на OpenMP, то форма виснет пока все это не посчитается. Если создать еще один поток QThread и кинуть ему данные на обсчет с помощью OpenMP, то почему-то функции OpenMP перестают работать, точнее при вызове функции из потока вылетает исключение, что "Инструкция обратилась по адресу //=//=//=, память не может быть 'read'". Обычно такое возникает при одновременном доступе потоков к одному ресурсу, но у меня инструкции OpenMP используются только в одном потоке. Использование QMutex перед вызовом OpenMPшных функций не помогает. Я был бы рад услышать ваши соображения по данной проблеме, заранее благодарю.

1)  Нитка из которой запускаются праллельные вычисления сама также считает, не нужно надеяться что она, мол, стоит и ждет.

2) Почему не работает из др. нитки - не знаю, может проблема не связана с OpenMP, нужно "потренироваться на кошках"

3) Простое решение вставить в расчеты

Просветите, пожалуйста, как?! Как удалось избавиться от Sementeation Fault?

А известно, когда исправят? Там предложен патч для openmp, но пока не представляю как его применить и пересобрать под винду: openmp идёт же вместе с mingw?

Здесь был поднят вопрос о том, что в gcc есть баг (пока еще неисправленный), который встречается при работе с OpenMP. На него я как раз наткнулся. А другой пользователь в самом начале говорил, что в VC2008 все нормально работает. И хотел бы спросить, как работать с Qt в вместе с VC, то есть что нужно скачать, прописать, настроить? Ничего этого, я увы не знаю, а делать задание нужно. Может что присоветуете. А, а под линуксом с gcc такая же проблемма?

Мне предстоит перетаскивать на Вындоуз, но через 1-2 месяца. На OSX все работает как доктор прописал, на gcc (даже 4.2), так и на Intel компиляторах. Срастается с Qt без проблем. В любом случае кроме библиотеки и хедера (omp.h)  нужна установка компиляции -fopenmp, я задаю это в IDE, должно иметь тот же эффект в командной строке.

Я скачал это: ftp://ftp.qt.nokia.com/qt/source/qt-win-opensource-4.6.2-vs2008.exe - по идее само собирается, но ещё не пробовал. Ну и Visual Studio Add-in (44 MB) наверное нужен, если в VS писать, собирать: http://qt.nokia.com/downloads

Поставил, попробовал: пока не собирается из-за отличий g++ и ms C++. Как включать OpenMP в VS есть здесь: http://msdn.microsoft.com/en-us/library/fw509c3b(v=VS.80).aspx, однако неизвестно, есть ли этот функционал в VS Express версии.

У меня собралось под VC++ и работает. Что интересно: скорость в debug версии у g++ и VC++ примерно одинаковая, интересно будет с оптимизацией проверить. OpenMP в VS работает прекрасно, в отличии от MinGW, однако медленнее, чем без OpenMP: видимо я лишнего распараллелил - много накладных расходов, будем убирать лишнее.

Что интересно: для моей программы (много циклов и вычислений) gcc сгенерировал примерно на 25% более быстрый код, чем Visual C++. Это с O2 - почти в равных условиях так сказать (у gcc был march=athlon-xp, у MS аналогичной опции не нашёл - видимо её и нет). При O3 и всех опциях оптимизации в MS соотношение примерно то же - на 22% gcc быстрее, и собранная g++ программа работает чуть медленнее, MS - немного быстрее.

TDM's GCC/MinGW32 тоже извещена об этой проблеме:
http://sourceforge.net/tracker/?func=detail&aid=2921774&group_id=200665&atid=974439

Я вижу на сайте GCC есть новые выпуски, никто не знает, исправили ли они эту проблемму?
Нужен совет, скоро уже диплом а нужно OpenMP+Qt в QThread, что мне делать, на чем собирать? Скачал компилятор Intel, не представляю, как им пользоваться, доки нормальной не нашел :( И будет ли компилироваться проект на уже готовой скаченной Qt SDK 2009.03? Подсоветуйте пожалуйста.

Я на др. платформе (OSX) так что в общих чертах

а) Дока на Intel хорошая, но если не надо выжимать скорость - проще на gcc, т.к. несмотря на все достоинства, у Intel свои заморочки. Напр. если поставить линкеру "Dead strip code" - валится на exception. Разобраться можно, но это время.

б) Также я использовал старенький gcc 4.2 но взял libgomp.a от gcc 4.4 - работает нормально, комбинируется с QThread без проблем, приятно. Что будет на Вашей платформе - не знаю, но попробовать стоит

Собирай в Линуксе - там этой проблемы нет.

ошибка -1073741515 в винде при работе в openmp связана с отсутствием в C:\Qt\2010.03\mingw\bin библиотеки pthreadGC2.dll (скачиваете с инета и все работает).
У меня получилось запустить openMP следующим образом:
1. ubuntu linux
   в make-файле добавил руками в поле CXXFLAGS  -fopenmp
   в файле .pro добавил поле QMAKE_LFLAGS += -fopenmp
2. windows xp
    скачал pthreadGC2.dll
    в файле .pro добавил поле QMAKE_LFLAGS += -fopenmp

Благодарю, может пригодится когда.

Здраствуйте, столкнулса с подобной проблемой: нужно в Qt задейсвоватть openMP, для разпаралливания цикла for.
Итак
1. Создаю QtCreator новий консольний проект.
2. Добавляю строки в Проект\\ Настройки сборки\\ Етапи сборки\\ Кликаю напротив qmake "подробнее" и прописиваю в строке "Допольнительние параметри"
3. Пишу код в файле *.сpp, што нужно прописивать перед циклом фор которий нужно розпаралелить. Например

   t_start = omp_get_wtime();
   #pragma omp parallel default(none) shared(A, b, c, N) private(i, j, sum)
   for (i=0; i < N; i++) {
      sum = 0.0;
      for (j=0; j < N; j++)
         sum += A[j] * b[j];
      c = sum;
   }
   t_end = omp_get_wtime();
   printf("%10ld %20.15f\n", N, t_end - t_start);

4 Єсть аналог функций
   t_start = omp_get_wtime();
   t_end = omp_get_wtime();
они засекают время работи цикла.

а= (double *)malloc(n * sizeof(double));
резервируєт облать памяти.

Работаю на в Qt 2010.05? WinXP SP3

P.S. Извините за ошибки я толька учусь

Чего "прописивать"-то?  :)
Если просто распараллелить цикл, то так

C++ (Qt)
double sum = 0.0;
#pragma omp parallel for shared(sum)
for (int j = 0; j < N; j++)
  sum += а[j] * b[j];
 

А внешний цикл (по i) смысла не имеет, т.к. считает одно и то же. Наверное что-то напутали, задачу уточните

кажется LIBS += -lgomp
и ключ компилеру -fomp
Это работало на маке/линупсе, думаю на вин тоже самое (если мингв)

Харащо а насчет
функций
   t_start = omp_get_wtime();
   t_end = omp_get_wtime();
они засекают время работи цикла.

а= (double *)malloc(n * sizeof(double));
резервируєт облать памяти.

warning: statement has no effect

это вопрос или что? есть ф-ии. надо подключить хедеры