| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > какие аргументы против OpenMP? |
| Автор: boostcoder 19.6.2011, 17:37 |
| всем снова драске буквально второй день увлечен OpenMP. и вопрос: почему все до сих пор пишут многопоточный код руками? ведь в 90% случаев OpenMP сделает то же самое, но только лучше! а главное - никакого рукоблудства! спасибо. |
| Автор: boostcoder 19.6.2011, 17:53 |
пример сложного случая пожалуйста. зы нет. понятно, что нельзя в начале основной программы написать "#pragma parallel" и надеяться что вся программа распараллелится. |
| Автор: kemiisto 19.6.2011, 18:17 | ||
Аргумент один - shared memory нинужен. |
| Автор: boostcoder 19.6.2011, 18:18 |
не у всех дома кластера стоят. Добавлено через 1 минуту и 8 секунд хотя... на сколько я Вас знаю, если бы тема была про MPI, то и тут Вы нашли бы что и как обложить. |
| Автор: kemiisto 19.6.2011, 18:25 | ||
Да причём тут кластеры?
OpenMP и MPI должны остаться в кровавых 90-х вместе с сишечкой и прочей мерзостью. |
| Автор: boostcoder 19.6.2011, 18:35 |
да, попутал. говорю же, второй день в теме. а по сабжу будут аргументы? Добавлено через 39 секунд применительно к с++. |
| Автор: kemiisto 19.6.2011, 19:27 |
Ну, я к тому, что shared memory как модель параллельного программирования даёт очень много возможностей выстрелить себе в ногу. Тебе это, конечно, не испугает... К тому же, ты правильно заметил, что OpenMP - это только shared memory, а если есть в распоряжении система с распределённой памятью (distributed memory), то придётся скрещивать OpenMP с MPI. Достаточно один раз увидить такой код, чтобы понять, что такой хоккей нам не нужен. Сейчас набирает популярность partitioned global address space. Типо - лучшее из двух миров. Гугли, читай. Вот, http://cnx.org/content/m20649/latest/. |
| Автор: boostcoder 19.6.2011, 19:36 | ||
спасибо. Добавлено через 12 минут и 1 секунду
но стОит заметить тот факт, что при помощи OpenMP вероятность такого исхода сильно сокращается, чем в сравнении с рукокодным кодом. |
| Автор: VictorTsaregorodtsev 19.6.2011, 20:47 |
Потому что изучил ВинАПИ (в том числе и потоки-процессы - по книжке Рихтера, которую перевели и издали на русском в 1995) задолго до появления документации по ОпенМП Зачем тратить время на освоение инструмента, дублирующего уже изученный? Ведь есть много возможностей исследовать что-то действительно новое |
| Автор: boostcoder 19.6.2011, 20:51 | ||
затем, чтоб потратить его один раз, и не заниматься рукоблудством вечно. |
| Автор: Earnest 20.6.2011, 08:49 | ||
Просто обеими руками ЗА. Невозможно вечно точить лопаты, надо и делать уже что-нибудь полезное. Если что-то хорошо знаешь, то руками делаешь быстрее, да и лучше... Это же не самоцель а просто инструмент (параллельное программирование в данном случае) |
| Автор: asmdzen 20.6.2011, 10:02 | ||||
что стоит почитать по этой теме чтоб не писать код уровня 90х? |
| Автор: fish9370 20.6.2011, 10:04 | ||
тем более, если это уже оформленно в виде библиотек, готовых модулей и т.д. мало кто лепит новый проект с нуля.. |
| Автор: boostcoder 20.6.2011, 10:06 |
OpenMP это не просто библиотека. это еще и поддержка со стороны компилятора. что и позволяет ему(OpenMP) быть таким простым и мощным, и избавляет от рукоблудства и человеческого фактора. |
| Автор: fish9370 20.6.2011, 10:12 |
| а как эта библиотека включается в проект? |
| Автор: boostcoder 20.6.2011, 10:17 |
| при использовании gcc, ничего в проект включать не нужно. просто добавляешь опцию -fopenmp если будешь напрямую использовать функции из нее в своем коде, заинклудь omp.h кстати, вот snapshot gcc-4.7.0, собрал на днях: http://try-catch.ru/library/compilers/i686-pc-mingw32-bin-4.7.0-snapshop-20110617-rev-0.tar.lzma. LTO+OpenMP+Graphite искаропки Добавлено @ 10:18 [оффтоп] особенно порадовал LTO. ну и c++0x: thread, mutex, atomic, condition и все что там есть [/оффтоп] |
| Автор: fish9370 20.6.2011, 10:34 |
| а в каких известных проектах используют? |
| Автор: kemiisto 20.6.2011, 10:41 |
Во многих HPC (High Performance Computing) проектах. На кластерах всяких. Для распределения задачи по кластерным нодам используют MPI, а уже в рамках одной кластерной ноды - shared memory посредством OpenMP. |
| Автор: REZiaMIX 21.6.2011, 18:03 |
| + никакого рукоблудства - так и не поймешь принципа работы многопоточности , если начинать сразу с openmp |
| Автор: kshubin 29.6.2011, 21:49 |
| простите что влазию в тему но очень стало интересно... появился ряд вопросов... 1. а чем openMP лучше или хуже того жу intel c++ который может сам оптимизировать код под многоядерный проц (ну кроме того, что под проц интел и он платный...) 2. если есть задача, которая уже написана на с++ для сложных ресурсоемких вычислений. предлагается сделать вычислительный кластер, который к примеру будет иметь одну управляющую ноду и 4 вычислительные. как и с помощью чего переписывать код? как это должно потом работать? подскажите что почитать плиз... |
| Автор: xvr 30.6.2011, 13:54 | ||||
Вы же сами и написали - сам оптимизировать. В OpenMP это отдается в руки программиста. Кроме того, когда это делаешь сам руками, можно увидеть узкие места и переделать алгоритмы и структуры данных. В случае автомата, эти места увидит компилятор, но не факт, что он вам об этом скажет. И уж точно он не станет за вас переделывать алгоритмы и структуры данных (хотя может и попытается)
MPI |
| Автор: FCM 3.7.2011, 16:11 | ||||
Скажет, если включить соотв. report-опции c соотв. уровнем подробности. Даже может столько сказать, что тошно читать будет. Но все равно OpenMP круче, т.к. переносимее, разнообразнее и может сработать там, где автоматика откажется.
Наверное, все же нужно явно линковать библиотечный файл libomp - по крайней мере в mingw-g++ (win). |
| Автор: boostcoder 4.7.2011, 16:27 | ||||
вот вы мне их и подскажете. я их долго искал.
ну хз.. в моей сборке mingw этого делать не нужно. можно просто сам mingw собрать так, что он линковал эту либу при использовании "-fopenmp" |
| Автор: xvr 5.7.2011, 09:29 | ||
Есть 2 но - они не документированы, и они вообще могут отсутствовать в релизной версии компилятора. А тут есть 3е но - полностью разобраться в них может только человек, достаточно хорошо знакомый с устройством компиляторов Хотя у Intel есть продукт как раз для 'разобраться' - Parallel Studio |
| Автор: boostcoder 5.7.2011, 09:35 |
для линукс использую http://valgrind.org/docs/manual/hg-manual.html ;) Добавлено через 1 минуту и 54 секунды но и у libstdc++ есть встроенная миниподдержка обнаружения подобных ошибок: http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html#debug.races правда, я еще не разбирался с ней. |
| Автор: FCM 5.7.2011, 10:24 | ||
Насколько помню в Intel C++/ Intel Fortran 12 win /Qpar-reportn - где возможные значения n: 0,1,2,3 |
| Автор: boostcoder 5.7.2011, 10:46 |
| FCM, скажите, вы где-то в теме смогли обнаружить упоминание какого-либо компилятора кроме gcc? ;) |
| Автор: FCM 5.7.2011, 10:50 | ||
См.
|
| Автор: boostcoder 5.7.2011, 11:01 |
| FCM, ааа, понял. сорри. |
| Автор: xvr 5.7.2011, 11:59 |
| Кстати, на Linux у icc компилятора есть масса недокументированных ручек для настройки оптимизаций. Список ручек доступен по опциям -mIPOPT -mP1OPT -mP2OPT -mP3OPT -mPGOPTI и -mPAROPT (только не забудьте подать какой нибудь файл на компиляцию, можно даже не существующий) Под Win эти списки тоже доступны, но будут называться немного по другому (не помню точно, как именно) Добавлено через 1 минуту и 29 секунд Это не совсем то. Parallel Studio умеет не только ошибки искать, но и давать советы по тому, как можно запаралелить программу |
| Автор: boostcoder 5.7.2011, 12:07 | ||
есть варианты для Linux? |
| Автор: xvr 5.7.2011, 12:56 |
Да, Intel Parallel Studio XE заявленна под Win и Linux |
| Автор: boostcoder 5.7.2011, 13:00 |
нужно попробовать... а у нее и GUI есть? оО или в каком виде она предлагает оптимизации/изменения? Добавлено через 2 минуты и 59 секунд гугл не показывает ни одного скриншота по запросу "intel parallel studio xe linux screenshots"... |