QT + OpenMP

Я что-то не очень понял, ты используешь openmp в Qt приложении?!

Так ведь надо -fopenmp, если правильно помню.

warning: ignoring #pragma ompa

Потому, что не ompa, а omp надо писать.

А может нинадо ни чего писать, а в кутях искользовать QThread?!

думаю у ТС пока еще мало опыта в Qt поэтому тащит в новый уютненький Qt свой старенький опыт с OpenMP

Привет. Думаю ТС гонит откровенно, если бы хоть чуть чуть понимал что такое Qt, вряд ли пришло в голову использовать openmp.

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

>Думаю ТС гонит

Подумай еще и не гони на ТСа. У автоматического управления потоками по сравнению с «автоматизированным вручную» таки могут быть преимущества - зависит от задачи. Морда на Qt + ядро с openmp, чем не вариант. В RTFMах по многопоточности обычно советуют рассмотреть возможность в том числе автоматического управления. (Некоторые, набаловавшись самописными диспетчерами/планировщиками/пулами переписывают на openmp и радуются.)

Значит ему надо для начала хотя бы почитать про Qt, чтоб хотябы понять что это не гуи библиотека а тулкит, который может чуть ли не всё вообще :) И что юзать с классами Qt свои велосипеды, не имея не малейшего представления что у них под капотом будет крайне сложно.

ТС изучи для начала основы Qt, врубись что он из себя представляет, что делает/не делает QObject, как работает взаимосвязь потомок-родитель (хотя бы чтоб с памятью работать мог) и что такое сигнал-слот, как оно работает. Потом почитай про QThread, а потом почитай хотябы это, врубись в изложенный материал, иначе у тебя ничего хорошего не выйдет.

В правильно спроектированной Qt программе QThread с вероятностью 99% покроет все потребности по многопоточности.

Часто бывают задачи по интеграции существующего числодробильного софта, на переписывание которого под Qt или твой любимый $FRAMEWORKNAME(ТМ) целиком (тем более - на «правильное проектирование под Qt» с нуля) денег никто не выделял. Потому что openmp ядро уже покрыло все 100% потребностей заказчика по числодроблению, а ему хочется раздать клиентегам красивые «кривые роста» и прочую sexy-визуализацию «холодных числ».

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

Ты памятник себе воздвиг нерукотворный... Взобрался на кочку^Wлюбимый фреймворк и токуешь. Можно подумать Qt - панацея, не имея именно что понятия о том, что как-то жили до него и после него жить как-то будут. (А некоторые проги переживут и «тулкит(ТМ)» - потому «морды» и моды на тулкиты меняются, а что-то просто работает, с тех времен, когда этих твоих «тулкитов» в проекте не было. Приносит профит здесь и сейчас, а не когда «молодо зелено» придет со своими представлениями о правильных велосипедах.)

>таким лучше подумать о смене профессии.

Снобизм такой снобизм.

К сожалению Вы, видимо, не совсем понимаете до конца матчасть. И тут дело вовсе не в Qt, а в OpenMP. Например, эта библиотека позволяет запускать большие циклы в несколько потоков даже не переписывая код цикла. Если для каждого такого цикла городить свои QThread - вот это уж точно велосипед получится.

Не совсем так. Боюсь, что в данном конкретном случае ТС и сам не знает чего хочет. ЗЫ про матчасть, OpenMP не просто библиотека.

К сожалению Вы, видимо, не совсем понимаете до конца матчасть. И тут дело вовсе не в Qt, а в OpenMP. Например, эта библиотека позволяет запускать большие циклы в несколько потоков даже не переписывая код цикла. Если для каждого такого цикла городить свои QThread - вот это уж точно велосипед получится.

Подписываюсь под словами.

P.S. Если дело не в ошибке в «#pragma ompa», то: для сборки с OpenMP надо передавать -fopenmp компилятору и -lgomp линкеру.

>ЗЫ про матчасть, OpenMP не просто библиотека.
Тут Вы совершенно правы. К сожалению поработать с OpenMP так и не пришлось. Только читал о ней слайды и HowTo, так что сам могу плавать в терминологии.

Тут проблема куда похуже, скажем ТС сделает распаралеленный на OpenMP цикл, допустим переберающий контейнер указателей на потомков QObject, попутно дергая какие-то методы объектов. Вопрос, кто блин контролировать будет? OpenMP не сделает произвольный QObject потокобезопасным. ТС оставил впечатление о себе как о человеке способном такое выкинуть, так что пусть лучше почитает, как я указал выше. Думаю ему не повредит освоить для начала простые потоки, автоматика это хорошо, но она сподвигает людей (особенно начинающих) не думать.

>ТС оставил впечатление о себе как о человеке способном такое выкинуть

Зато вы оставили о себе впечатление как о человеке, наделенном буйной фантазией и склонностью к поучениям на ровном месте. Из наперстка фактов извлекаете вёдра выводов. (Офигенный КПД.) Произвольный QObject можно и с QThread сделать «потокоопасным», не прилагая никаких специальных усилий.

Вопрос, кто блин контролировать будет?

Переформулируйте, пожалуйста, вопрос. Контролировать что? При чем тут блины? (ТС такой проблемы не ставил. Ну и... нет такой проблемы.)

распаралеленный переберающий

Лучше вот это проконтролируй(те). Это в ваших силах (если не в интересах).

как я указал

Фрейд ликует. Вершина вербального доминирования. «erfea - голова! Ему палец в рот не клади! Лично я не положил бы» (с) Жизненная практика учит, не указывать незнакомым людям, что им делать. Чтоб они не сказали, куда вам идти.

Произвольный QObject можно и с QThread сделать «потокоопасным», не прилагая никаких специальных усилий.

Эммм, ты так считаешь?

Переформулируйте, пожалуйста, вопрос. Контролировать что?

Угадай, что надо контролировать при обращении к методам объектов из разных потоков?!

Фрейд ликует. Вершина вербального доминирования. «erfea - голова! Ему палец в рот не клади! Лично я не положил бы» (с) Жизненная практика учит, не указывать незнакомым людям, что им делать. Чтоб они не сказали, куда вам идти.

Ты нервный, подлечись...

Да не в этом... это как то случайно попало сюда...

вот мой .pro

# -------------------------------------------------
# Project created by QtCreator 2011-04-25T11:45:52
# -------------------------------------------------
QT += core
QT -= gui
TARGET = «тут название...»
CONFIG += console
CONFIG -= app_bundle
TEMPLATE = app

SOURCES += ну и список файлов
HEADERS += ну и список

QMAKE_LIBS+=-lgomp
QMAKE_CXXFLAGS+=-fopenmp
QMAKE_LFLAGS += -fopenmp

----------------------------------------
в файле с кодом

#include <omp.h>

#pragma omp

КОД...

И в итоге:

warning: ignoring #pragma omp
warning: ignoring #pragma omp reduce

----------
Прога консольная из QT использую только QString QByteArray для парсинга файла, распаралеливаь естественно это не собираюсь,

99% проекта С++ без какого либо QT там вот и пытаюсь.

Мне просто удобно так... графическая среда норм...

99% проекта С++ без какого либо QT там вот и пытаюсь.

Нафига тогда такого монстра тащить? Бесят такие проекты, когда зависимостей уйма. Особенно вьювер секондлайв, там в зависимостях и GTK и Qt есть, вообще маразм :(

ЗЫ если таки собираешься делать и дальше так же, для начала попробуй cmake.

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

О_о кто сказал что при переносе проекта на другую систему сборки (особенно убогенький qmake) время экономится.

У меня это работает:

QT += core
QT -= gui
TARGET = name
CONFIG += console
CONFIG -= app_bundle
TEMPLATE = app
SOURCES += a.cpp b.cpp
QMAKE_CXXFLAGS+=-fopenmp
LIBS+=-lgomp

а как с помощью qthread сделать что-то подобное?

#pragma omp parallel for
for (i = 0; i < N; i++) {
    a[i] = 2 * i;
}

Линкеру тоже надо говорить -fopenmp. Так более кроссплатформенно.

Линкеру тоже надо говорить -fopenmp. Так более кроссплатформенно.

Зачем? И в чем кроссплатформенность?

компилятор какой и какой версии?

в том, что на icc нет никакого gomp'а

в том, что на icc нет никакого gomp'а

А в VC++ вообще другие флаги. На всех не угодишь.

ага, поэтому Ъ-way юзать cmake

> warning: ignoring #pragma omp

warning: ignoring #pragma omp reduce

Хорошо бы посмотреть полный код прагм.

И еще - другие программы с OpenMP компилируются нормально?

Элементарно: или CUDA привлечь, или (если на CPU надо) вызывать в цикле pthread_create =)

pthread_create нет в винде и слишком муторно

А при чем здесь винда? Или человеку надо кросплатформенное нечто?

Да и не так уж и муторно: в цикле вызываем pthread_create, затем в следующем цикле - pthread_join. Если потоки могут вызывать коллизии - создаем до циклов мьютекс, а в функции, выполняемой потоками, перед опасным участком вызываем pthread_mutex_lock, а после него - pthread_mutex_unlock.

давай напиши, а мы потом посчитаем число строк

Вот работающий пример вычислений на CPU.

А вот - то же самое на CUDA.

Я спрашивал про QThread. pthread_create и CUDA это совсем не кроссплатформенно.

Ну дык додумайте по аналогии. Я вам что - кутешник, что ли?

Кстати, CUDA - очень даже кроссплатформенно. Главное, чтобы видеокарта у человека нормальная была.

Я знаю как это все пишется. Руками городить обвязку над pthread'ами слишком муторно, что ты и продемонстрировал. Я лет 6 назад тоже так писал. Но сейчас я обленился и использую openmp. Благо работает оно везде, в том числе и на венде.

Так это не библиотека, а отдельный компилятор?

Это расширения компилятора. Все современные компиляторы кроме clang'а openmp держат.

Кстати, CUDA - очень даже кроссплатформенно.

Вот где будет работать Qt:

• *nix/X11;
• Mac OS X;
• Windows;
• Embedded Linux;
• Windows CE / Mobile;
• Symbian;
• Maemo;
• OpenSolaris;
• Haiku;
• OS/2;
• Amiga OS4;
• iPhone;
• Android;
• webOS;
• Amazon Kindle DX;
• *nix/Wayland.

А что там у CUDA?

Главное, чтобы видеокарта у человека нормальная была.

Оставь свой максимализм. AMD была, есть, и будет. Да и Intel — отличные видеокарты. Во всяком случае, беспроблемные.

Точно, почитал man gcc:

This option implies -pthread, and thus is only supported on targets that have support for -pthread.

> цикле вызываем pthread_create, затем в следующем цикле - pthread_join. Если потоки могут вызывать коллизии - создаем до циклов мьютекс, а в функции, выполняемой потоками, перед опасным участком вызываем pthread_mutex_lock, а после него - pthread_mutex_unlock.

Гг. Так студни, курсе на 2-м, понтуются «умением писать многопоточные приложения».

А мне не нравится, когда графика тормозит. И всякие 3D из десятка миллионов треугольников я хочу крутить в реальном времени, а не как слайдшоу!

Работает - и фиг с ним :)

Ось сабжевая? компилятор?