Комментарии 20
Очень интересно, спасибо!
А какие задачи вы решали с помощью этой технологии? Хотя бы в общем.
А какие задачи вы решали с помощью этой технологии? Хотя бы в общем.
Скрининг по гомологии, алгоритмы группы genbee, www.bri-shur.com
Сейчас там стоит OpenMP шная версия т.к. два серверных nehalem рвут по производительности достаточно слабую карточку GF120 на текущем (честно говоря — очень тяжелом для массового параллелизма) алгоритме.
На моем же рабочем компьютере FERMIшная GTS450 ненамного, но обходит i5-650.
FERMI, по моему опыту, гораздо лучше работает с «плохими» алгоритмами, хотя там еще пахать и пахать.
Сейчас только что закончилась конференция ПаВТ-2011, выступал представитель NVIDIA представляя CUDA 4. Говорил что одна из основных задач — уменьшить специфичность программирования граф. ускорителей.
Но до конца все равно не удастся, все равно будет SIMD. Может, хоть с памятью разберутся — сейчас приходится играть с банками данных и распараллеливать данные даже на чтение (именно в этом Fermi лучше предыдущих архитектур).
В общем, все очень интересно, параллельное программирование — очень отдельная и сложная тема, распараллеливать алгоритм на миллион ядер пока никто не умеет, а уже нужно.
Сейчас там стоит OpenMP шная версия т.к. два серверных nehalem рвут по производительности достаточно слабую карточку GF120 на текущем (честно говоря — очень тяжелом для массового параллелизма) алгоритме.
На моем же рабочем компьютере FERMIшная GTS450 ненамного, но обходит i5-650.
FERMI, по моему опыту, гораздо лучше работает с «плохими» алгоритмами, хотя там еще пахать и пахать.
Сейчас только что закончилась конференция ПаВТ-2011, выступал представитель NVIDIA представляя CUDA 4. Говорил что одна из основных задач — уменьшить специфичность программирования граф. ускорителей.
Но до конца все равно не удастся, все равно будет SIMD. Может, хоть с памятью разберутся — сейчас приходится играть с банками данных и распараллеливать данные даже на чтение (именно в этом Fermi лучше предыдущих архитектур).
В общем, все очень интересно, параллельное программирование — очень отдельная и сложная тема, распараллеливать алгоритм на миллион ядер пока никто не умеет, а уже нужно.
В целях восстановления кислотно-щелочного баланса расскажу немножко про CUDA.
«Цена вхождения» в эту технологию гораздо ниже, чем многие думают. Видеокарта (GF8600 или любая более новая) и компилятор C — это всё, что требуется для работы (желательно иметь вторую видеокарту или второй комп с GPU для дебаггера GPU-кода). Загрузить CUDA и GPU Computing SDK — и всё, можно работать. Документация очень подробная, примеров в SDK полно, также к вашим услугам весьма компетентный форум на nvidia.com. Причём писать можно сразу на OpenCL — он у NVIDIA вполне нормальный, afaik.
С недавнего времени для предварительной отладки сложных алгоритмов можно использовать MATLAB — там есть возможность запускать код на GPU. Ну и свои библиотеки у NVIDIA вполне достойные — CUFFT, CUBLAS, NPP.
В общем, дерзайте. Мне странно, что у такой перспективной технологии у нас в России до сих пор столь небольшое количество пользователей.
«Цена вхождения» в эту технологию гораздо ниже, чем многие думают. Видеокарта (GF8600 или любая более новая) и компилятор C — это всё, что требуется для работы (желательно иметь вторую видеокарту или второй комп с GPU для дебаггера GPU-кода). Загрузить CUDA и GPU Computing SDK — и всё, можно работать. Документация очень подробная, примеров в SDK полно, также к вашим услугам весьма компетентный форум на nvidia.com. Причём писать можно сразу на OpenCL — он у NVIDIA вполне нормальный, afaik.
С недавнего времени для предварительной отладки сложных алгоритмов можно использовать MATLAB — там есть возможность запускать код на GPU. Ну и свои библиотеки у NVIDIA вполне достойные — CUFFT, CUBLAS, NPP.
В общем, дерзайте. Мне странно, что у такой перспективной технологии у нас в России до сих пор столь небольшое количество пользователей.
По докладу пермяков (у них индустриальный подход, попробовали под свой алгоритм обе технологии и все доступные ускорители, и Intel и AMD, штук 8) на их задаче не было разницы в скорости CUDA-OpenCL, а AMDшные решения оказались чуть быстрее.
С подходом (CUDA-заказные, OpenCL-универсальные) соглашусь. Впрочем, внутренняя логика программирования у этих технологий практически одинаковая, они оба достаточно низкоуровневые и «железо» диктует и возможности, и проблемы.
С подходом (CUDA-заказные, OpenCL-универсальные) соглашусь. Впрочем, внутренняя логика программирования у этих технологий практически одинаковая, они оба достаточно низкоуровневые и «железо» диктует и возможности, и проблемы.
Я еще не написал про грабли, связанные с банками памяти… Но это уже тонкие оптимизации, доступные в документации. В статье я постарался сконцентрироваться на не вполне очевидных вещах, без которых нельзя программировать даже если знаешь саму технологию. В документации они описаны, по моему мнению, недостаточно.
Тоже довольно долго бодался с OpenCL.
Я бы в статье выделил ещё тот факт, что наибольшая производительность технологии достигается при использовании векторов, векторных операций и текстур (изображений). Поэтому лучше сразу проектировать алгоритм с данными, запакованными в int4/float4.
Я бы в статье выделил ещё тот факт, что наибольшая производительность технологии достигается при использовании векторов, векторных операций и текстур (изображений). Поэтому лучше сразу проектировать алгоритм с данными, запакованными в int4/float4.
clCreateImage3D…
Я еще не написал про грабли, связанные с банками памяти… Но это уже тонкие оптимизации, доступные в документации. В статье я постарался сконцентрироваться на не вполне очевидных вещах, без которых нельзя программировать даже если знаешь саму технологию. В документации они описаны, по моему мнению, недостаточно.
Грабли не о технологии, а о спецификации. Незабывайте пожалуйста, что опенцл это всего-то спецификация, которая говорит что должна быть платформа, язык програмирования, железо и логика. А вообще я вам дам чтиво, а вы уж там сами как-нибудь…
www.cmsoft.com.br/index.php?option=com_content&view=category&layout=blog&id=41&Itemid=75
developer.amd.com/documentation/articles/Pages/OpenCL-Optimization-Case-Study.aspx
developer.amd.com/documentation/articles/Pages/OpenCL-Optimization-Case-Study-Simple-Reductions.aspx
www.cmsoft.com.br/index.php?option=com_content&view=category&layout=blog&id=41&Itemid=75
developer.amd.com/documentation/articles/Pages/OpenCL-Optimization-Case-Study.aspx
developer.amd.com/documentation/articles/Pages/OpenCL-Optimization-Case-Study-Simple-Reductions.aspx
Если пишите штучное ПО под которое можно подобрать аппаратную часть, то лучшим вариантом будет CUDA у неё кстати есть возможность выделять память динамически, но если массово, OpenCL не оставляет вариантов, потому как например говорить геймерам купите себе карточку NVIDIA для того что бы увидеть супер реалистичную физику в игре — это плохо.
а карточки Tesla вообще используются в этих решениях? а то большинство статей, что я читал про работу с CUDA, говорили об использовании обычных видеокарт и слабом приросте в реальных задачах по сравнению с CPU.
Все зависит от задачи.
Топовые графические карты быстрее и дешевле Tesla.
Но
1) У них меньше объем (видео)памяти. Это критично, например, для нашей молекулярной динамики — большую модель просто не загрузишь.
2) На них менее надежные вычисления. Если на игровой карте раз в час игры промелькнет артефакт, это допустимо. А вот если неправильно посчитается тот же реактивный двигатель… На теслах есть контроль памяти по четности, для критичных алгоритмов, которые считаются сутками, это критично, иначе придется покупать две карты, запускать одинаковые задачи и сравнивать результат для верификации.
3) Сам встречался с тем, что на граф. карте есть предел по времени на одну нитку вычислений, если она «думает» больше, считается зависшей и прибивается, для графики это допустимо — для вычислений — нет.
Насчет же эффективности — у вышеупомянутых двигателистов и распознавателей речи выигрыш в десятки раз, причем это наши разработки. Для молекулярной динамики — выигрыш по ссылке в статье и он тоже очень серьезный.
В общем, все зависит от задач. Сейчас нам (программистам) светит смена парадигмы программирования, переход на параллелизацию всего и вся. Постараюсь в ближайшее время по материалам конференции написать на Хабре статью.
Все это очень интересно, придется много учиться.
Топовые графические карты быстрее и дешевле Tesla.
Но
1) У них меньше объем (видео)памяти. Это критично, например, для нашей молекулярной динамики — большую модель просто не загрузишь.
2) На них менее надежные вычисления. Если на игровой карте раз в час игры промелькнет артефакт, это допустимо. А вот если неправильно посчитается тот же реактивный двигатель… На теслах есть контроль памяти по четности, для критичных алгоритмов, которые считаются сутками, это критично, иначе придется покупать две карты, запускать одинаковые задачи и сравнивать результат для верификации.
3) Сам встречался с тем, что на граф. карте есть предел по времени на одну нитку вычислений, если она «думает» больше, считается зависшей и прибивается, для графики это допустимо — для вычислений — нет.
Насчет же эффективности — у вышеупомянутых двигателистов и распознавателей речи выигрыш в десятки раз, причем это наши разработки. Для молекулярной динамики — выигрыш по ссылке в статье и он тоже очень серьезный.
В общем, все зависит от задач. Сейчас нам (программистам) светит смена парадигмы программирования, переход на параллелизацию всего и вся. Постараюсь в ближайшее время по материалам конференции написать на Хабре статью.
Все это очень интересно, придется много учиться.
«На них менее надежные вычисления.» — Я не согласен. Вы о каких картах сейчас? Потому, что в спецификации OpenCL есть конкретно то как должно работать с флоат-поинт арифметикой: «Defines consistent numerical requirements based on IEEE 754». У CUDA етого нету. Я сам сравнивал разброс подсчета больших матрих на GPU и CPU, и я практически не видел разницы в том, кто считает лучше, и там и там были очень похожии разбросы.
Я про неустойчивость результата при длительных вычислениях (сутки и более).
Даже на конференции один из докладчиков рассказывал, что при подсчете на двух картах получались разные результаты. Проверифицировали третьей, одна оказалась несколько глючной. Это критично на научных задачах.
Также опираюсь на статью в журнале «Суперкомпьютеры», её, к сожалению, нет на их сайте. Там сравнивались теслы и топовые игровые карты.
Даже на конференции один из докладчиков рассказывал, что при подсчете на двух картах получались разные результаты. Проверифицировали третьей, одна оказалась несколько глючной. Это критично на научных задачах.
Также опираюсь на статью в журнале «Суперкомпьютеры», её, к сожалению, нет на их сайте. Там сравнивались теслы и топовые игровые карты.
А какие выводы из этих сравнений тесл и игровых карт?
Если я не ошибаюсь, так китайцы себе поставили суперкомпютер на АМД картах. А для устойчивости они их подтактировали…
Пруф линк искать не буду.
Если я не ошибаюсь, так китайцы себе поставили суперкомпютер на АМД картах. А для устойчивости они их подтактировали…
Пруф линк искать не буду.
Выводы я уже озвучил — для больших по времени или памяти задач — тесла.
О! Нашел-таки на сайте статью!
Сейчас на первом месте китайский комп на tesla. Вроде был еще один на amd
http://hitech.newsru.com/article/15nov2010/cnno1
но в последних рейтингах я его не нашел, видимо произвели апгрейд на тесла.
китайцы на www.top500.org
О! Нашел-таки на сайте статью!
Сейчас на первом месте китайский комп на tesla. Вроде был еще один на amd
http://hitech.newsru.com/article/15nov2010/cnno1
но в последних рейтингах я его не нашел, видимо произвели апгрейд на тесла.
китайцы на www.top500.org
Спасибо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
OpenCL: Как заставить эту штуку работать